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(57) Abstract 

A system and nicthod for providing computeriTed. knowledge- 
based medical diagnostic advice. The medical advice is provided to the 
genera) public over a networic, such a.^ a telephone network with the 
use of a telephone or the Internet with the use of an Internet access 
device. Alternatively, the medical advice can be provided to a patient in 
a stand-alone mode by use of a computer. The invention utilizes a list- 
based processing method of generating and executing diagnostic .scripts. 
For the purpose of diagnosing a health problem of a patient, medical 
knowledge is organized into a list of the diseases to be considered. Each 
disease on the disease list includes a list of symptoms thai is checked in 
a patient. Each symptom on the symptom list is then further described 
as a response to a li.st of one or more que.<;tions asked of the patient about 
the symptom. This triply-nested list structure is convened by suitable 
data structure transformations into a script that is stored. When a patient 
requires diagnosis, the script is played back as a sequence of questions. 
The responses of the patient are analyzed aixl converted into symptoms. 
The symptoms arc accumulated into diseases. Finally the diseases are 
selected iind reported as n diagnosis. 
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COMPUTERIZED (tflEDECAL DSAGCSOSTIC SYSTEM UTILOZIKG UST BASEO PStOCESSIffiG 

Bacfeorounrf of the Inventfon 

Field of the Invention 

The present invention relates to computerized medical diagnostic systems. More specificaliy, the inventbn is 
directed to a computerized system for time-based diagnosis of a patient's complaint by use of dynamic data structures 
Description of the Related Technolopv 

Heafth care costs currently represent a significant portion of the United States Gross National Product and are 
rising faster than any other component of the Consumer Price Index. Moreover, usually because of an inability to pay 
for medical services, many people are deprived of access to even the most basic medical care and information. 

Many people delay in obtaining, or are prevented from seeking, medical attention because of cost, lime 
constraints, or inconvenience. If the public had universal, unrestricted, and easy access to medical information, many 
diseases could be prevented. Likewise, the early detection and treatment of numerous diseases could keep many patients 
from reaching the advanced stages of illness, the treatment of which is a significant part of the financial burden 
attributed to our nation's health care system. It is obvious that the United States is facing health-related issues of 
enormous proportions and that present solutions are not robust. 

Previous attempts at tackling the health care probtem have invohred various forms of automation. Some of these 
attempts have been in the form of a dial-in library of answers to medical Questions. Other attempts have targeted 
providing doctors with computerized aids for use during a patient examination. These methods involve static procedures 
or algorithms. What is desired is an automated way of providing to a patient medical advice and diagnosis that is quick, 
effiaent and accurate. Such a medical advice system should be modular to allow expansion for new types of medical 
problems or methods of detection. 

One way of conducting an interview of a patient includes medical diagnostic scripts. What is needed is an 
efficient method of representing the medical knowledge of experts in their specialties m a script format. The scripts 
should utilize dynamic structures to quickly and efficiently reach a diagnosis of the patient. 

Summary of the Invention 

List-Based Processing is a method of diagnosing diseases that works by arranging diseases, symptoms, and 
questions into a set of nested Disease, Symptom, and Question (OSQ) fists in such a way that the Osts can be processed 
to generate a dialogue with a patient. Each question to the patient generates one of a set of defined responses, and 
each response generates one of a set of defined questions. This estabHshes a diatogue that eficits symptoms from the 
patient. The symptoms are processed and weighted to rule diseases in or out. The set of ruled-in diseases estabOshes 
the diagnosis. A Ust-Based Processing system organizes medical knowledge into formal, structured fists or arrays, and 
then appfies a special algorithm to those fists to eutomaticaQy select the next question. The responses to the questions 
tead to more questions and ultimately to a diagnosis. 
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In ona endtodiment of the ktvention, there is a computerized diagnostic method, comprising the steps of providing 
to a computer a Gst of diseases, each disease associated with a fist of symptoms, and each symptom associated with 
a list of questions; repetitively asking questions to eKcit responses, the responses establishing symptoms, each established 
symptom contrSiuttng 8 weight to a disease; and determining whether the accumulated t»etghts for a dbaase reach or 
5 pass a threshold so as to declare a diagnosis. 

The medical advice system also includes a geographic-based list of differential diagnoses in the population in 
which the patient resides, which, when processed by the list-based processor, is turned into a patient specific differential 
diagnosis. The system, also inchides a table in whkh the frequency of the diseases is kept to aRow the system to 
evahiate the patient using the probabBttias or incidence of diseases in the population in which the patient resides. The 
10 system may also give patient specific and conteirt sensitive recommendationlsl for the laboratory test(s) of choice and 
the onaging modaGty of choice to further help define a diagnosis. The system may invoice a '^re-enter*' function to allow 
for the laboratory test(s) of choice and the ffnagtng modafity of choice to be performed and then the results to be 
conveyed to the patient, the patient's health care g*nrer(s| andior any other desbed entity. The system may invoke the 
"re-enter** function to allow a patient to perform physmal eBamtnatton maneuvers (on self or via an assistant) and re- 
15 consult the system to further refine the diagnosis. 

Brief Descriotton of the Drawings 
Figure la is a blocEt diagram illustrating components of a presently pref^red embodiment of the computerized 
medical diagnostk and treatment advice (MDATA) system of the present invention; 

Figure lb is a block diagram fflustrating components of the user/patient computer of the iWDATA system shown 
20 on Figure la; 

Figure 2 is a block diagram illustrating a set of processes, files, and databases utifized by the system of Figure 

la; 

Figure 3d is a diagram of an off-line medical diagnosis script (^S) generation process used in producing a script 
file for the ii/IDS database shown in Figure 2; 
25 Figure 3b is a diagram iBustrating a possible hierarchy of the DSQ lists for a script at two different time 

intervals; 

Ftgure 4a is a flow diagram of an assign diseases portion of the "collect and organize medical knowtedge" 
process shown in Figure 3a; 

Figure 4b is a ftow diagram of a capture disease knowledge portion of the "collect and organize medical 
30 knowledge process" shown in Figure 33; 

Figure 5 is a f tow diagram of the "scrg)t compSer" process shown in Figure 3d; 

Figure 6a is a block diagram showing a configuration used during operation of the diagnostic script engine; 
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Figure 6b is a bloch diagram showing a set of structures and inputs used during operation of the scrqit engine 
and the outputs produced by the SIDDATA system; 

Figure 7 is a top ievel fbw diagram of a user process for the MOATA system of Figure 1; 

Figure Ba is a fhiw diagram of the "diagnostic script engine* process used m performing the on-fine interview 
process shown in Figure 7; 

Figure 8b is a flow diagram of the "distribute advice" process shown in Figure 8a; 

Figure 9 is a flow diagram of portions of the "DSQ list script engine' process shown in Figure 83 for fist-based 
processing; 

Figure 10 is a block diagram showing a portion of the lists utrtized during operation of the DSQ list script engine 
shown in Figure 8a; 

Figure 11 is another flow diagram ol the °DSQ list script engine" process shown in Figure 8a; 

Figure 12 is a flow diagram of the "select symptom" (select symptom to be considered) process identified in 
Figure 11; 

Figure 13 is a flow diagram of the "handle response" (process response from the user) process identified in 
Figure 11; 

Figure 14 is a flow diagram of the "update disease lists" (update scores in disease temp fist based on updated 
symptom list and elbninate diseases ruled-in or ruled out) process identified in Figure 11; and 

Figure 15 is a high-level flow diagram of an alternative embodiment for generating medical advice or a diagnosis 
in the MDATA system of Figure la. 

Detailed Description of the Preferred Embodimeni 
The following detailed description of the preferred embodiment presents a description of certain specific 
embodiments of the present invention, flowever, the present invention can be embodied in a multitude of different ways 
as defined and covered by the claims. In this description, reference is made to the drawings wherein like parts are 
designated with fike numerals throughout. 

For convenience, the discussion of the preferred embodiment will be organized into the following principal 
sections: System Overview, Medical Diagnostic Scripts, Knowledge Capture Details, Script Generation DetaEs, Scnpt 
Elocution Details, and Advantages of List-Based Processing. 

I. System Overview 

A Medical Diagnostic and Treatment Advice (MDATA) system is a con^uter system that conducts automated 
interviews of patients for the purpose of estabfishmg a medical diagnosis. To conduct the interviews, MDATA uses a 
database of Medical Diagnostic Scripts (MDS). Each MDS contains the data and commands needed to interview a patient 
for a specific medicel conditbn and to output a diagnosis. Scripts are supported by other MDATA databases of dbeases, 
symptoms, treatments, medications, speciafists - in short, aD information required for medical diagnosis and advice. 
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Symptoms can be defined as a piece of historical information, a piece of nformation elicited from a physical eHaminatton, 
e.g^ physical signs usually from a self-examination, the results of a laboratory test, or the results of an imaging modafity 
of choree. 

Referring to Figure la, a block diagram of a presently preferred embodEment of the {\/IDATA system 100 will 
5 be described. The MOATA system 100 includes a network "ctoud" 102, which may represent a local area network (LAN), 
a wide area network (WAN), the Internet, or another connection service. 

The MDATA programs and databases preferably reside on a group of servers 108 that are preferably 
interconnected by a LAN 106 and a gateway 104 to the network 102. Ahematively, the MOMh programs and 
databases reside on a single server 1 1D that utiTaes network interface hardware and software 1 12. The MDATA servers 
10 108/110 store the disease/symptom/question (DSQ) lists described hereinbelow. 

The network 102 may connect to a user computer 116, for example, by use of a modem or by use of a 
network interface card. A user 114 at computer 116 may utibe a browser 120 to remotely access the MOATA 
programs using a keyboard and/or pomting device and a visual display, such as monitor 118. Alternatively, the browser 
120 is not utilized when the MDATA programs are executed in a local mode on computer 116. A vkleo camera 122 may 
15 be optionally connected to the con^uter 116 to provide visual input, such as visual symptoms. 

Various other devices may be used to communicate with the MDATA servers 108/110. If the servers are 
equipped with voice recognition or OTMF hardware, the user can connnunicate with the MDATA program by use of a 
telephone 124. A telephonic embodiment is described in AppGcant's copending application entitled ''Computerized 
Medical Diagnostic and Treatment Advke System," U.S. Serial No. 08/176,041, which is hereby mcorporated by 
20 reference. Other connection devices for communicating with the MDATA servers 108/110 inchide a portable personal 
computer with a modem or wireless connection interface, a cabte interface device 128 connected to a visual display 130, 
or a SBtellitB dish 132 connected to a satellite receiver 134 and a television 136. Other ways of aOowing communication 
between the user 114 and the MDATA servers 1081110 are envismnad. 

Referring to Figure lb, a diagram of a presently preferred user/patient computer shows several possible 
25 interconnections to the network. To "play' a script, a special program called a Script Engine is used, which reads a MDS 
fDe and uses its codes to perform interview actions, such as outputting a question to a patient and inputting an answer. 
The scripts also collect the answers from the patient, evaluate the answers, issue a diagnosis, and update the patient's 
medical record. The script engine preferably resides in the user computer. The script engme may be stored on the hard 
drive or CD-ROM, and is toaded into the main memory or a cache for execution. 
30 The components of a presenthf preferred computer 116, utiEzed by a user 114 of the computerized MOATA 

system 100 of the present invention, are shown in Figure lb. Altemathrety, other devices for conducting a medical 
interview, such as those shown in Figure la, can be utSized in place of the computer 116. 
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The computer 102 includes a plurality of components within an enclosure 116. A telephone line 106 mterfaces 
the public telephone network 158 to the computer 116 via a modem 160. The telephone network 158 may connect to 
the network 102, which has connections with the MDATA system serverls) 108/110. Ahemativety, the user may 
connect to the network 102 by use of a network interface card 164. 

Throughout this document, the words user and patient are used interchangeably. However, it will be understood 
that the user may be acting as a proay for the patient. If this is the case, the user is registered as an assistant far 
the patient. 

The hardware and system software are assembled with two basic concepts in mind: portabifity to other 
operating systems and the use of industry standard components. In this way, the systwn can be more f tesibte and win 
allow free market competitjon to continually improve the product, white, at the same lime, decreasing costs. BWiile 
specific hardware and software may be referenced, it wiU be understood that a panoply of different components could 
be used in the present system. 

The computer 116 preferably is a personal computer wHh an Intel Pentium microprocessor 170. Other 
computers, such as an Appte (Wacintosh, an Amiga, a Digital Equipment Corporation VAX, or an IBM mainframe, could 
also be utiliied. The modem 160 or the network interface card 164 connect to an industry standard architecture (ISA) 
or a peripheral component interconnect (PCI) bus 162. The bus 162 interconnects the microprocessor 170 with a 
phirality of peripherals through controOer circuits (chips or boards). 

The computer bus 162 has a phirality of peripherals connected to it through adapters or controllers. A video 
adapter board 172. preferably at SVGA or better resolution, interconnects to a video monitor 118. A serial 
communication circuit 176 interfaces with a pointing device, such as a mouse 178. A parallel communication circuit may 
be used in place of circuit 176 in another embodiment. A keyboard controller circuit 180 interfaces with a keyboard 
182. A 500 Mb or greater hard disk drive 184 and an optional CD-ROM drive 186 are preferably attached to the bus 
162. The hard disk 184 stores database files such as the patient fOes, other MDATA files, and binary support ffies. 
The CD-HOFW drive 186 also stores database files, such as files for the patients usmg the computer 116, and binary 
support fSes. 

A main memory 190 connects to the microprocessor 170. In the presently preferred embodmient, the computer 
116 preferably operates under the Windows 95 operating system 192. The memory 190 executes a diagnostk: script 
engine 194 and a disease/symptom/question (DSO) Est script engine 196. The script engine software is written in 
Borland Oe^hi Pascal, version 11. 

ftof erring to Figure 2, a set of processes, files, and databases utilized by the MDATA system 100 wffl be 
described. Eacept for the script engine process, the MDS database, the Imaging Modafity database, and the Laboratory 
Test database, which are described hereinbetow, these processes, fBes, and databases were described in Applicant's 
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copending application entitled "CompotsriiBd Medical Dtagnosttc and Treatment Mmte Syatero." U.S. Serial Bo. 
08/176.041. 

The MDATA system 100 utSizes several princ'^a! processes and retated databases. A set of patient login 
processes 210 b used by the system 100 to identify a patient who has previously registered into the system in one of 
three ways: 1 1 by prompting for a patient identification number m: 2) identify an assistant who has previously 
registered into the system by prompting for an assistant identification number (AIM); 3) Usntify a patient, having an 
assistant, who has previously registered into the system by prompt'oig for the patient identification number. A set of 
processes 212 are used to register a patient or assistant. If the user is the patrant, a patient registration process is 
used by the system to register new or first tsne patients. If the user is not the patient, an assistant registration process 
is used by the system to register new or first-time assistants. Then, if the patient is not already registered, an assisted 
patient registration process is used by the system to register the patent. 

Once a user has logged in or registered, the system provides a choice of processes. The prsnary process of 
concern m the current embodiment is the Diagnostic process 220 that performs a patnnt diagnosis. The evahiation 
process 220 accesses a laboratory test of choice and imaging modality of choice database to recommend the appropriate 
tests in this patbnt at this point in time and a treatment table 250 to obtain current treatment information for a 
particular disease or diagnosis. In another embodiment, other choices are added to access other medical information 
processes. 

Associated witli these processes are a patient and assistant enrollment database 240. a consultation history 
database 242, a patient response database 244. a medical history objects database 246. a patient medication database 
248. a pending database 25Z a patient medical history database 254, a medical diagnostic scripts (MDS) database 256. 
an imaging modality database 258. and a laboratory test database 260. 

II. Wedical Diagnostic Scriots 

A KAedical Diagnostic Script (MDS) is a programmed dialogue with a patient for the purpose of generating one 
or more diagnoses of the patient's condition. Developing an MDS invohres several steps such as capturing the medical 
diagnostic ttnowledge. espressing it in terms that a patient can understand, errenging it into a useful sequence, compiling 
it into a playable script, testing h, configuring it for a specific communication medum. embedding it mto a collection of 
other scripts and support databases, and packaging it for use by the patient. 

"Writing a script" is considered to mean the early steps of capturing the medkal knowledge and processing it 
into a logical question stream that uhnnatehr leads to a diagnostic conclusion. Obviously, only a physkian experienced 
in diagnosing a specific set of diseases can perform these steps, and the MDATA system has developed several 
automated methods to support them. 

The invention preferably utilizes one particular method, called 'fist-based processing.* which begins with Ssts 
of ifiseases. symptoms, and questions. These fists are then processed mto a playable scr^t using a list iiased script 
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dBVBlopmeni tooL Using the script development tool the author can write and edit the source script, compile it into a 
playable script file, play the script back, and set various script options to exenise, evahiate. and fine-tune the script. 

A list-based script consists of a speciany fomiatted text file in which the author provides the elements of the 
script in the form of several lists. The top list is a Est of diseases which the script wiD consider. For each disease, 
the script fists the symptoms and their weights. For each sympton^ the author provides a Est of questions and their 
weights that wiU eficit the symptom. For each question, the author provides multiple text objects, inchiding a preambte 
text that introduces the question. After aO of the lists have been prepared for a script, the next step is to -compile- 
the script, ie. to convert it into a specialy encoded script file that can be pbyed bach, or "run." lor a patient. To run 
a script in the development phase, the script development tool setects a suitable next disease and a suitable next 
symptom for that disease. It displays the question text and waits for a reply from the patient. Based on the patient's 
response, the script devebpment tool updates the disease scores and continues with the next symptom. The script stops 
when some condition (set by the author) is reached, such as the first disease being ruled m as a diagnosis, or aH diseases 
having been considered. 

During the development phase, the script author can set various 'options- that witt change the way the script 
selects the next disease and the next symptom, and how long the script win run. This option feature lets the author 
expermtent with the saipt to find the best settings. 

The three main phases of a script, therefore, are: 1) knowtedge capture, 2) script generation and 3) script 
execution. The script author utilizes an three phases in the creation and testing of a script. A patient utilizes the script 
execution phase during run time use of the MDATA system 100. 
PHASES OF A SCRIPT 
1. Knowtedge Capture 

The knowledge capture phase includes all of the tasks needed to extract from a medical expert the knowledge 
about diagnosing a ghren disease and reducing that knowledge to some form useful in generating a script. The phase 
typicaHy begins with a director of script davetopment expressing a need for a script for diagnosing a disease such as 
Malaria, it continues with tasks such as defining the scope of the script, researching medical texts, interviewing authors 
and other experts, formatting the question and response sets, establishing the question sequence, and. if an automated 
knowledge capturing tool is used ruraiing the question flow in a test setting. This phase ends with a set of source 
documents, possibly automated, that (at least) contains aU of the inf omution needed to write a script that can correctly 
diagnose the disease, e^,.. Malaria/Not Malaria when it is fed test responses for a patient that does/not have Malaria. 
Nothing B known at thb point about the ultimate form of the script, the platform on which it will run, or even the 
natural language it will be using to communicate with the patnnt. 
2. Script Cagieratton 
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In the script generation phase, the script is generated as a relatively smaD diagnostic algorithm captured in 
software. In this phase, the goal is to tet the script be an automated representstton of the author's approach to 
diagnosing a disease or other medical problem, such as Malaria. The script contams data and processes to produce a 
good first question, to weigh the response, to use the response to generate another question, and so on until the script 
5 can finally teD its caller that the responses indicate Malaria or E^ot Malaria, and the associated level of confidence. 

Note that a script is not a stand atone program that can be run for a real patient. The script preferably only 
knows about a single chief complaint, such as Malaria, and does not diagnose other meifical problems such as Gout or 
Asthma. 

This script is destined to become one of approximately 40,000 scripts in the Script Database, in much different 
10 form and format. The script now has to be translated into the appropriate human language (German, Spanish), 
supplemented with appropriate error handling mechanisms, generated into the appropriate programming language iC^*, 
Java, HTML), formatted for the appropriate target medium (PC, Mac, Telephone, LAN, MN, Internet), and Knked to the 
Support System (databases, meta functions, patient records, session logging). 

Next, the script undergoes extensive testing in a testbed thai feeds the script various canned sets of patient 
15 responses, vtrith ttnown acceptable diagnoses, to verify that the script does generate the appropriate output. 

Finally, the script is ready to be installed into a production system. It may be stored into a massive Script 
Database, or packaged into a set of scripts to be written to a CD ROM or shipped via the Internet to a hospital. 
Whatever the form of the script library used, the scr^t wiO have to be indexed and registered wiU be with the Script 
Manager software. At the end of this phase, the script ts at last part of an official, running medical diagnostic system 
20 that can be used on real patients for real diagnoses of real problems. 
3. Scritpt Esectstet 

In the script execution phase, the script is actually executed, sooner or later. Of course, a session with a 
patient does not start with a diagnostic script on Malaria. A medical diagnostic system open to the general pubftc 
obviously has a number of admin^trathre tasks to perform before it gets down to any medical diagnosis. First of aD, 

25 it does not want a patient acutely deteriorating while we ask for a password and Social Security Number. So the 
system most fikely first runs the Emergency Room (ER) subsystem for anyone who togs on to the MDATA system. The 
ER subsyston consbts of a few dozen scripts that determine whether the patient has any Ofe threatening conditkm that 
needs immediate **first aid** therapy or advice. "Is this a medical emergency?", "Does the patient have an airway?", "Is 
the patient bleeding?" are some of the questions the ER subsystem asks. 

30 After the system weeds out the emergency cases, the system can stow down to identify the patient and 

determine the Chief Complaint(s). Then the system invokes the Script Routing subsystem, whose job b to determine the 
patient's general problem area. Based on this information, the Script Routing system next selects a sequence of top-level 
scripts that are appropriate to the patient's Chief Complaint. For example, for fever, after the more obvious scripts for 
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Appendicitis. Intestinal Flu, Food Poisoning hove indicated "Wo OiaBnosis.- the Rooting script mar finally decide to try 
iWaJaria. Wow, at last the sample Materia saipt m have developed in this document is played. 

Scripts are not programs that run themsehres. Scripts are data streams that «e run by a 'script engine" that 
searches the script for the ne>t question to ask of the patient, and formats the question for transmission (to a screen 
a telephone line. « an Internet site). The patient responses are also captured by the script engine, formatted for the 
scrjpt, and used to select the m»t question from the script. This interplay of the script and its script engine may 
consider the patent's medical record, the information provided so far during this sessioa and e»en some meta functions 
to determine the next question. At the end of the script, the process returns control to the Tropical Dkease Routing 
Scnpt and says, in effect, "this patient's responses indicate Malaria Falciparum with a weight of 1350 out of 1000 " 
or -this patient's responses only add up to 420 out of 1000. so I rule out Malaria." The Routing script that caUed the 
iVialaria script in the first place may now decide to access another diagnostic script, or may decide to return to its caller 
some response such as "the patient's responses indicate only a 275 / 1000 likelihood of having eny tropical disease " 
SCRIPT FEATURES 

Ttnis-BBsed Diagnostic Scripts 

The rme-Based Diagnostic Script concept extends the DSQ diagmistic scripts in the time dimension. Instead 
of just one diagnostic script, the script author now submits several scripts. e.g, one for each hour into the disease 
process. Scripts are generated at an elapsed time from the beginning of symptoms, according to the best judgment of 
the author. For example, a myocardial infarction script would use one hour or less as an interval, while malaria would 
not. At run time, the diagnostic system uses the diagnostic script closest to the patient's case. The script has implied 
symptoms that add extra weight to diseases that match the predated pattern. 

The system esks the patient when the symptoms started, and, partially based on that information, selects the 
appropriate script from the time based set of scripts. Once the right script is selected, the script is executed. That is. 
each script of a set of time-based scripts may have somewhat different symptoms and weights, so that the author sets 
up time based symptoms with extra weights for those diseases whose time pattem matches the patient's. These weights 
are automaticalhr added by the script engine es it runs. Note thet these time based symptoms wiB be ImpRed Symptoms, 
descr&ed hereinbefow. 

Each algorithm author must compose, assign, or calculate the questions and the appropriate vahms at (for 
instance) each hour as the disease progresses. Then, when the patient consults the system, one of the first questions 
to ask is "When (or how tong ago) did your symptoms begin?" Then that patient win interact with the script that b 
closest to the lapsed isne since the syniptoms(s) begaa 
Implisd Stm^rtoms 

Note that a "symptom" is defined as any data item known about a patient, directly or indirectly, including name 
age. gender, and so forth. An Implied Symptom is a symptom that is established based on the presence or absence of 
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one or more other symptoms The bnplied Symptom concepts allows the scrqit author to tell the script engme that any 
given symptom (or set of symptoms) tmplws or denies one or more other symptoms. TMs lets the author embody real- 
world relationships into the Ust-Based script, which, in turn, lets the LB Engine make logical inferences that eGminate 
superfluous questions from the list and make the script more focused. 

As an obvious enample, a patient who is a man does not have to be asked questions rebted to the female 
reproductive system. A human doctor knows this impticitty, but the script engine needs to be tokL The scr^t author 
ssnply makes a &st of symptoms in the form: 

IF Symptom A THEM Symptom B. 
For eiample: 

"patient is male* knplies "patient is NOT female/ and 

"patient had Appendectomy* impEes "patient has no Appendix.* 
Using the logical operators such as AND, OR or NOT, it is possible to build quite complicated symptom relationships that 
are triggered by relatively few questions. 

Implied Symptoms are listed in the source script as a table of "IF A THEN B* type statements. Whenever the 
engine receives a new symptom from the patient, it also checks the Implied Symptom table to see if any other symptoms 
are knplied. 

Synergistic Symptoms 

Synergistic Symptoms are symptoms that indicate that, in any given patient, a certain set of other symptoms 
is present that have special diagnostic significance when they occur together. In a DSQ List-Based source script, each 
symptom has a certain specific weight toward diagnosing a disease, but the presence of a certain set may lend extra 
weight toward a diagnosis. For example. Malaria is classically diagnosed starting with the presence of Chills, Fever, and 
Sweating (which are caused as the Malaria-caus'mg agent goes through its r^roductive cycle in the blood). The presence 
of ChBIs or Fever or Sweating separately would probably not necessarily suggest pursuing Malaria as a diagnosis in a 
patient, but the assertion of aQ three of these symptoms should trigger an inquiry about Malaria. The concept of 
Synergists Symptoms supports this internal trigger with a statement such as: 

"has Chais" AND "has Fever* AND "has Sweating" impties "Possible Malaria' Synergbtic Symptoms elso have an 
important use in defming a Syndroms, le., particular collations of symptoms that occur together so often that, to the 
lay pubKc, they have their own name, such as AIDS. The script author can use Synergistic Symptoms to define a 
Syndrome that is mnportant to tum/her. 

IIL Knowledae Capture Details 
The initial task of knowledge capture for a saipt is identifying the diseases to be inchided in the script, 
assigning a priority to each disease, and assigning medical speciafists to develop the portions of the script for their 



wo 98/02836 PCT/US97/12025 

-11- 

assigned diseases. Each medical speciafist then generates the appropriate lists needed for the (fiseases. This can be 
summarized as follows: 

o define the scope of diseases to be covered; 

o list the diseases and their symptoms; 

o assign rankings, priorities, and weights to diseases and symptoms; 
o design properly worded and weighted questions that win eScrt the symptoms; 
o format the disease, symptom, and question lists; 
o pre test the Gsts» using tast tools spectaOy developed for the purpose; and 
o write the fists as text files, using any ASCII-capable word processor. 
The list-based processing method begbs with a set of coordinated lists that captures the elements of diagnosing 
a particular health problem. In this phase, medical experts record their diagnostic skills and techniques in the form of 
several lists. To do this, the experts preferably can use any commercially available word processor software that is 
capabte of generating an ASCII output ffle. 

The ASCII lists for a script consist of three types of lists that are nested as follows: 

o one Disease List that identifies aN the diseases the script wdl consider, and ranks them in the order 

they should be considered for diagnosis; 
o one Symptom List for each disease that identif^s the symptoms and assigns a weight to each 
symptom to define the contrOiutton it makes to diagnosing the disease; 

o one Question List for each symptom that identifies one or more weighted questions that will elicit the 
symptom from a patient. 

For the purpose of automated medical diagnoses, medical diagnosis data is organized into a hierarchical 
classification that is based on the general concept that diseases have symptoms, and symptoms are elicited from the 
patient by questions. 

A 'disease* is a health condition that requves treatment or attention such as illness, ailment, affliction, 
condition, state, problem, obstruction, malfunction, and so forth. To diagnose a patent with a ghfen complaint, the 
MOATA system begins with a Nst of possible diseases that exhibit the complaint and reduces this to a list of diagnoses, 
based on the patient's answers. 

A "symptom* is any information that the MDATA system has about the patient. This includes: 

<3 patient identification (e.g., name, address, HMO, age, sex); 

° patient history (e.g., prior Olnesses, parental health information, recent travel to foreign countrtes); 
o previous accesses to MDATA (e.g., history of patient complaints and progress); 
^ physical signs (e.g., vital signs) and the results of self* or assisted- physical examination maneuvers; 
o lab and test results; 
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o signs, manifestations, presentations, aspects, and so forth. 
For each disease, a Nst of symptoms is prepared. Each symptom is assigned a weight, which represents a ikoKhood that 
the patient has the disease, given the symptom. To shiplify calculations, the MDATA system uses a ruled in threshold 
vahie of 1,000 to declare a disease as diagnosed, ahhough other threshokts may be used. The system abo utilties a 
ruled out threshold to offrcially declare that the patient does not have the disease. Both the ruled in threshold and the 
ruted out threshold may be modified by a sensitivity factor set. This permits customized threshold levels, for example, 
for individual patients. The sensitivity factor set will be further discussed hereinbelow. 

In practice, the weight is a measure of the diagnosing physician s willingness to rule the disease in, given the 
symptom. The weight can also be used as a Conditional Probabifity that the patient has the disease, given the symptom. 
This can be used, if convenient, to apply a Bayesian Probability analysis to the symptoms. 

A symptom is elicited by a set of one or more questions, often interlaced with information and instructions on 
how to answer the question. The set of nodes needed to eficit a symptom is called a "flow" because it typically invohres 
a branching flow of questions, often drawn on a small flowchart, that descnbes how a dialogue with the patient might 
proceed. 

To enter the diagnostic data developed by the medical expert into the MDATA system, the data must be 
organized and formatted. For this purpose, a text fSe is used and a text file format was developed. The ASCII character 
code is preferably utilized, but any well-defined text-character code, such as EBCDIC, could be used. 

A script consists of several segments or data groups as follows: 



A. 


DISEASES to be diapnosed in terms of werghted syniptnnM; 


B. 


SYMPTOMS to be elicited by fbws or impfied hy othpr nymptnnK- 


C. 


IMPLICATIONS that looicaily connect symptoms* 


D. 


FLOWS constslinp of paths through nodas; 


E. 


PATHS that visit question nodes: 


F. 


TEXTS that inform and/or advise the patient: 


G. 


QUESTIONS that ask the patient for a responsii; 


H. 


KEYS that signal a specific response from the patient. 



These segments are part of the foUowing sections of a script "source" or text file: 
Koadsr Section 

The Header section contains data that applies to the entire script, such as script format, and the set of 
symptoms comprising the patient's ch»f comptamt. 
DisessQs Socttion 

The Diseases section Ests the diseases that can be diagnosed by this script, their symptoms, and the 
symptoms' weight toward a diagnosis. When the script runs during the script development phase, the script 
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developnrani tool selects one of the diseeses to consider next, and timn selects one of that disease's symptoms to be 
considered nest. Which di^ase and symptom is selected nest depends on the Run Options that are selected by the 
author. The def aub sequence is the order in which the diseases and thetr symptoms are listed m this section. 
DiSEASEjmE 

The disease name is a unique label for a disease, used to identify the disease. It is only used intemaDy and 
will never be seen by the petient. 
iClh9J0DE 

A special code used by the medical profession to identify the disease. 
FORmiJITLE 

The formal title of the disease. The "formar title is used here because common names for the disease, or 
acronyms, may be added in future formats. 

svmproMjfAM 

The name of a symptom that is part of the diagnostic picture or "fingerprint" of the disease. The symptom 
is defined in detail in the Symptoms Section. In the OSQ list context, a 'symptom" b a specific, detailed fact about 
the patient that has been assumed, asserted, elicited, or inferred. The author is free to define any data itemis) as a 
symptom. If it is useful to the author, symptoms may inchide non medical facts such as name, rank, and serial niOTiber 
of the patient. The intent here is to give the author freedom to express his/her medical experience by defining elemantery 
symptoms and grouping them in any convenient way. 

To des^n a symptom, an author may knagina a set of weighted questions that would uniquely assert or deny 
the symptom. If this is no problem, the author defines the symptom (in the Symptom Section) in terms of its questions 
and answers. If the symptom turns out to be too complex, the author may break the symptom into parts, treat each 
part as a symptom, and ask questions about the part. The author may let the patient estabfish each part separately, 
and then use the inference mechanism of the Inference Section to estabHsh the main symptom; 

sreffpTOMWEieMT 

The amount that this symptom adds to the disease's total score. Technically, the amount can be any number 
from 10,000 to +10,000; realisticaDy it tends to be a smaU positWe integer. As written, the script engme treats 
weights as a way to "score* a disease. When a symptom b estabished as being present in the patient, the script engine 
adds the weight of the symptom to the total score of the disease. When the disease score preferably reaches 1,000, 
the script engine rules the disease "in." 

Simple arithmetic addition of weights may not express the specific way a symptom contrSiutes or "indicates* 
the presence of disease. One sohitbn for the author is to matte a first guess of the we^hts, run the script, observe 
how the disease scores change with each question and answer, and then go bach to "rebalance" the symptoms. 
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A "synergistic symptoms' techniqud may ba useful to the author in developing e strategy for the weights. If 
Xhm are two symptoms A and B that, if present together in a patient carry more weight than each separately, then 
an artifidat third symptom C can be defmad that is ir^fyd by both A and B and adds entra weight to the disease. 
Symptom C has no associated questions; it is an Enternal "ghost" symptom that can be used only to add or subtract 
5 weights based on the presence or absence of other symptoms. 
SvmpioD?ss SMtion 

The Symptoms section lists and describes all of the syndroms mentioned in other parts of the script. For each 
symptom, this section identifies the Flow of questions used to eficit the symptom. 

sruBFToasjfMm 

10 The symptom name is a unique label for a symptom, and is used to identify the symptom in other parts of the 

script. The name is only used internally, and will never be seen by the pattant. 

The word "flow" is used to describe a specific set of weighted questions, astted in a specified sequence that 
can be drawn as a flowchart. Thus, a flow represents a smgte group of questions. Since one flow can elicit one of 
15 several symptoms, several symptoms will typicaDy specify the same question fibw to be used. Some symptoms (e.g., 
chief complaint symptoms) have no associated question fbw. 
tmpticQtBons Section 

The Imprications sectbn lists the logical inferences among symptoms, so that the script engine knows which 
symptoms imply other symptoms. Each line of the section specifies one or more symptoms that together imply another 
20 symptom. That is, each fine gives the parameters for a logic formula of the form: 

lif symptom A and symptom B dnd symptom C then symptom D. 
Symptom tmpticetions can be chained, so that one enpOed syntptom can Imply another symptom, atone or in conjunction 
with others. 

One use of this section could be to establish "syndrome" symptoms, so that a specific set of symptoms in a 
25 patmnt would automaticelly assert & single, coBecthre symptom. This combination symptom could also be used to add . 
(or subtract) extra weight if a specific set of symptoms is present, Le., to allow for the "synergy" of several symptoms 
present in the patient at the same time. 
Flows S^t&on 

The Flows Section lists aD fh>ws in the script, and defines the sequence of questions and the symptoms thet 
30 can be elicited by the flow. A "flow" is short for "a question flowchart*. It can be thought of as a comples question 
that will establish one of several symptoms. Readers famiar with branch4)ased scripts wffl recognize that the flow can 
serve to conta'm or call an entire branch-based script that returns one of several response codes. 
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It is qurte common that one needs to ask a patient several questions to eOcrt one specific symptom from the 
patient. For example, some prcOminary questions ("Have you ever smoJtcd?') may be needed to set the stage, foDocved 
by quite specific questions |°«Vhat is the total time, in years, that you smoked?) to define the patient's symptom 
precisely. One ent^e flow may contain 20 questions about smoEcing and may eScrt one of several symptoms such as: 
has never smoked; h a casual smohcr; has smoked 20.pack years and stiD smokes; and smoked 10-pack years, then quit 
10 years ago. 

Every node in a flowchart is encoded according to the path from node one of the f iowf taken to get to the node. 
These paths are used to identify what action should be taken at each node. 
Questions Soctton 

The Questions section defines the details of the questions mentbned by name in the Flows section. The details 
include the Preamble, the actual Question, the keys that can be pressed by the patient (on a telephone keypad), and (for 
graphic mterfaces) the button label to be used for each answer. 

The Preamble is the teit spoken or displayed to the patient before the question itself is asked. It may continue 
after a previous question, introduce a new subject, define some terms, and inform the patient w/by a question is about 
to be asked, and how to answer it. Only the name of the text is given here; the actual text is ghren in the Texts 
Section. If there is no preamble for a question, this is indicated with the digit zero as a place holder. 

The Question text is the actual question. Whereas the preamble may be 10 or 100 tines long, the question h 
typically short, to the point, and calls for a very specific answer that can be indicated by pressing or clicking one of the 
keys. Only the name of the question text is ghren here; the actual text is ghren in the Texts Section. 

A set of Valid Keys tells the script engine which keys the patient can press or cHck. 

These are key labels, used only in graphic display versions of the script. They tell the engine how to label each 
button, for example YES, NO, and NOT SURL 
Tests Sestion 

The Texts section lists the actual text of aD text items referenced by name in other sect'ions, such as 
Preambles, Key labels, and Question Texts, By ghring each text a unique name, and listing the text in the Texts section, 
the author can use the same text in several places. 

Having aO of the text that is intended for the patient in one place also simplifies automated processing of the 
saipt, such as recording the text for use in a telephone network or formatting the text for display on a screen, A script 
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could be translated into a foreign language, by replacing tis Texts section text with 6he equivalent text in another 
lanpage. 

Referring to Figure 3a, en off ine process 280 for generating a DSQ script ifini notRr be described. Beginning 
5 at a process 284, medical bnowladga b coBscted end organized into Bst files. The data for the Cst files is collected for 
one or more medical authors 282. Process 264 has two portions. A first portion is typically performed by a script 
coordinator or supervising author for assigntng diseases, and a second portion for captur'mg the dbease hnowbdge for 
each disease in the scrqit. The portion for capturing the disease knowledge is typicaBy performed by a phjrality of 
medical experts in their respective fields. The assigned diseases portion of process 264 will be further described in 

10 conjunction with Figure 4a, and the capttffed disease knowledge portion of process 284 wtQ be further described in 
coniunctton with Figure 4b. The output of process 284 is electronic text, such as an ASCII tile. This electronic text 
is in the form of DSQ fists such as disease, symptom, and question lists 286. The Appmdis mchides an exemplary script 
for malaria. The script is one representation of a DSQ Gst. 

A graphical example of tene*based OSQ lists for a script is shown in Figure 3b. An exemplary script 320 for 

15 a time T, and a script 322 for a time Tj are shown. Each of these two scripts includes a fist of diseases 324, a fist 
of symptoms 326, and a list of questions 328. This figure is intended to show the hiwarchy of the disease, symptoms 
and question Ost, and is only exemplary. Note that a disease may refer to symptoms that are defined in other diseases, 
and a symptom may refer to questions that are defined in other symptoms. Thus, symptoms and their associated 
questions can be reused by the various medical authors. 

20 Returning now to Figure 3a, process 280 moves to state 290, which takes the DSQ lists in electronic text 

format and processes them by use of a script data development tool A script compiter 292 works closely with the 
script data development toot to generate an MOS f^e. The process 280 may utifize the saipt data development tool and 
the script compiler m an iterative fashion to generate a final MDS file. At state 294, the MDS file is written to an MDS 
database 300 by an MOS database manager utifity 298. The MDS file 296 is preferably in a binary format, bi an 

25 exemplary representation of the MDS fte shown in Figure 3a at 296', the AADS preferably includes a header data section, 
a master disease Est section, a master system Gst section, a master flows section, a master question list sectioa and 
a master text fist section. In another embodimoit, the medicd authors may write the scripts in a medical authoring 
language or as nodes and branches, es shown at state 302. Other scrqit toob, which may include compters, are shown 
at state 304 to generate m MDS 296. 

30 Referring now to Figure 4a, the assign diseases process 350 of the collect and organize medical knowledge 

process 284 wQl now be described. Process 350 w31 typicaBy be p^formed by a script coorifinator, ahhougb other 
medical professionals utifized by the MDATA system may perform these tasks. Process 350 preferably is not performed 
by a computer but by the script coordinator, who may utilize the computer to assist in the completion of the foBowing 
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Steps. Beeinnng at a start state 352, process 350 moves to a state 354, wherein ths ehtaf complaint associated with 
the current script is defined. The chief compteint mdodes the symptoms that a pattsnt mtght initially provide to the 
system whan describing the main problem that thay are constihtng for. Pfoceedmg to state 356, the script coordinator 
determinas a fist of the diseases that are to ba diagnosed by the current scrqit. These diseases should provide a 
diagnosis of the chief complaint. Included in the list are the disease name, a dascrqrtor, and an International 
Classification of Diseases (ICO g) code for the disease. Advancing to stale 358, the diseases are then ranked by 
probabiGty of occurrence in the general population that the patient is in, e.g., country or region of a country. Moving 
to state 3B0, the script coordinator assigns priorities to the diseases based on urgency andfor seriousness of the disease. 
Based on the assigned priorities, the script engine may be dkected to chectc first the diseasBs that have an urgent or 
serious mdtcation assigned to them. Continung at state 362, the script coordinator then partitions or assigns the 
diseases for the current script to one or more medical speciafots for further development Using a computer network, 
such as the hiternet. and a DSQ ists database, multiple scr^is can be developed in paraBel. The disease authors can 
worh in parallel by making questions and instructions available to aB the other authors via the database and the network. 
This capability aDows rapid development of the scripts. Process 350 ends at an end state 364. 

Referring now to Figure 4b, the capture disease knowledge portion 380 of the collect and organize medical 
knowledge process 284 will now be described. Process 380 is also not typicaBy performed by a computer, but is 
performed by a madicai speciaDst or eipert who may emptoy the use of a computer to actually capture the disease 
knowledge for a particular disease. The following steps are performed by the disease speciaKst, as assigned by the script 
coordinator at state 362 in Figure 4a. 

Beginning at a start state 382, process 380 moves to a decision state 384, wherein the medical speciafist 
determines if the script is bast captured as a tkne-based script. That is, a plurality of scripts at sequential time intervals, 
forming a script family, are to be generated to track the diseases over tene. If it is determined to be a time-based script, 
process 380 moves to slate 386, wherein the time interval between scripts in the script family is determined. For 
example, the script author may decide to generate a script for every two hours for a 48 hour time period. At the 
completbn of determining the time interval for the script famihf, or if the saipt is best shown as a single sci^t, process 
380 continues at state 388, wherein the medical specialist idmtif ies a rufog in threshokl score and a rufmg-out threshokt 
score for each disease that is assigned to him or her. Moving to state 390, the medical spedaltst identifies a set of 
relevant symptoms for each dbease assigned to them. The symptom list inchjdes the symptom name, a descriptor, and 
at least one weight as described hereinbelow. Continuing at state 392, the medical specialist identifies any relevant post- 
response relationships and symptoms identified by these rclaiionsh^s. The post-response relationships may inchide 
simultaneous or synergistic relationships where two or more symptoms occurring together may have more weight toward 
diagnosing a disease than the sum of the weights for the symptoms occurring ^arately. A sequential relationship is 
where the symptoms occur one efter the other, which may produce more weight toward diagnosing a disease then the 
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sum of the weights of the indreidual symptoms occurring separatety. A variation of the ^uenttal relationshtp is wherein 
the sequence of the onset or ending of the symptoms produces a different weight than the symptoms do alone. ImpGed 
relationships are wherein the presence of one symptom impGes the presence of another symptom. The medical author 
may also define relationships over time for the asserted symptoms and further post-response processed symptoms. The 
post-response relationships may also involve symptom clarification processing, f^RST array analysis, or a symptom 
severity clarification. The PQRST array is an N dimensionat array with different atlrbutes or aspects of the symptom 
of paffi asstgned to one dmiension. For enample, the PQRST array may have twenty-two dimenskins. 

Proceeding to state 394« the medicel specialist assigns a weight for each disease symptom* For symptoms 
having an associated range, such as a severity of pain or other type of symptom severity, the meAcal speciaGst may 
assign a range of weights associated with the severity of the symptom. Symptom weights are eccumulated into a score 
for each disease having the symptom. Weights can be ether positive or negathre, which contrbutes to the production 
of a posithre or negathfe score. Moving to state 396, for each symptom, the medical specialist defines a flow of 
question nodes to eGcit or determine the symptom. Some symptoms can be determined by a single question, but most 
symptoms may require a number of questions to elicit the symptom. For the symptoms requiring a plurality of questions, 
weights are assigned to the possible responses of the questions at state 397. Thus, this type of symptom may have 
a range of associated weights. Advancuig to stats 398, for each question node of the question flow, the medical 
specialist writes text objects for the question node so as to provide an introduction or an explanation, instructions, advice 
and the actual questions for the patient. The instructions may define the range of values that are requested (an answer 
set) or other ways of formatting the expected responses. The introductions and explanations are to help the patient 
understand what the question is about, why the question is bemg asked, and sets the stage for the possiile responses. 

For each symptom the author will compose a question flow that is used to eGcit the symptom. The question 
flow that the author uses may be another physician's question flow. For example, let's say the symptom is depression. 
To estabbsb the symptom of depression, one doctor may asEt, "Are you depressed?". This might be called 
deprBsston_question_1. Let's say that the author does not lihe it. It is too terse and reatty does not capture what is 
wanted. So the author looks further in the question database. The author may find and took at 
depresstOR_question_ftow_2. This question flow is much more elaborate. In this flow, to answer the question, "Are 
you depressed?", this doctor has davbed a ID-pomt Gst of questions. The sub-questions may even be other questions 
in the database. In this question f bw, the patent is asked ten questions. lEach question is weighted differently and, 
after answering all of the questions, the score is totaGed, and if it reaches a threshold defined by the question's author, 
then this physician wiS say that the patient has the symptom of depression. 

\n another exampte, say an author wants to ask a question about nausea for migraine. The author examines 
the question bank. The author may find fifty different questions on nausea. One question says, "Are you oau3eated7^ 
This question is not acceptable to the migraine author. Another author has a question flow that contains ten weighted 
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sub-questions. II their score reaches that author's prMlefined threshold, that doctor calls his patiant nauseated. The 
migraine author Ghes it almost as is. but wants to change one of the weqhts of one of the weighted sub-questions, 
in thb situation, the migraine eutfaor saves the new question with the revised weight as nausea_que$tion_n+l. i«ow 
when the migraine author uses the new version or another version of nausea, it will of course be weighted differently 
in defining different diseases. 

if questions of different weights are not aUowed in the question ftows, then aO the questions wS be. by 
definition, weighted the same. But when e disease author, trying to see if, say. abdominal tenderness is present, win 
ash the patient to do a series of maneuvers such as: "Please cough. Does thet make your abdomen hurt?" If the 
patient says "yes*, the disease author may then ask the patient to press on his abdomen and ask if that hurts. The 
disease author usually asks or requests the patient to perform many such maneuvers to estabfsh the "symptom- of 
abdominal tenderness. However, these questions are not aU of equal importance in defining abdominal temlerness. If 
a patient hurts wh»i his abdomen is pushed, that is much more significant than the coughing maneuver. 

After the question nodes have been completed at state 398. a medical specialist determines at a decision state 
400 if another time interval for a tone based script is required. If another interval is not required or if the present scrqit 
is not a time-based script, process 380 ends at a return state 402. However, if another interval a required m a time- 
based script, process 380 moves back to 388 to rerun the set of steps 388 to 400 for another time interval in the script 
family. 

iV. Script Generation Details 
Internal to the MDATA system. Esl based medical diagnosis data is stored as scripts. These fSes are the 
diagnostic interface between the human doctor and the patient being interviewed. At run Ime. a MDS fib "runs" by 
driving a script engine, which is a generic program that loads lUDS files and runs the saipt based on the data and 
instructions encoded in the file. Diagnostic data are stored in the form of disease, symptom, question, ami test node 
lists. 

The contents of a list-oriented iUOS file mirrors the contents of the ASCII list file. The major diKerence 
between them b that the text fite data b stored as segments of test ines of character strings, whereas the MDS Ob 
data b packed into Bsts of binary integers. A second difference » that the IMDS fib data b arranged and cross- 
referenced to support on-line access to the data. 

The ms f Oe is preferably formatted as one very large array of 32-bit binary integers. Thb large array b then 
aOocated into bhwbs of varying tength that contam data. Since the location oi a block n the f8e b itself a number, it 
can be used as a data item that connects one bbch to another btack. PhysicaOy. these blocks are mdepandent of any 
programming language or operating system and can be transported to any computer hardware that b capabb of storing 
fibs of 32 bit numbers. Logically, these Mocks can be nested and comncted in arbiUary ways to form data structures 
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such as Med Ksts, sJaclts, queues, trees, and networks. The (WDS fHe is formatted as several segment bloctts called 
'master Gsts* as foBows: 

o Header Data, 

o Master Disease List, 

o Master Flow Lbt, 

o Master Question List, 

o Master Symptom List, 

o Master Test List. 

To prepare a MOS He, the ASCI! fist Ke is read and converted into a MDS file by the script compiler. This 
process consists of readine the ASCII text fife nne-by-line, compffing the appropriate segment of the corresponding MDS 
output file, and generating cross-reference ists to speed searches. Since some symbols may be used before they are 
defined, the conversion program must make two passes through the file. During the first pass, all lines are read in. 
converted into MDS file blocks, and their symbols are saved in a table. During the second pass, symbols are replaced 
by their actual block addresses. Of course, other methods of compSation may be use! 

The conversion program can, of course, perform any number of quality and consistency checks, such as 
detecting invalid formats, missmg segments, duplicate symbob, unused symbols, typographical enors and so on, Cou(ded 
with a simple teit editor, the conversion program can let the script author make corrections in the ASCII list fite and 
then rerun the conversion program again until it accepts the file. This editing cycle serves to catch fundamental source 
errors and typographical errors early. 

After the script is compiled, the script author tests the script to determine whether it functtens as intended. 
If not, the script author may, for OHample, adjust symptom/question weights, fine-tune words and phrases for the question 
nodes, and fix any togical and medical errors. The script author wiB then recompile and rerun the script umB it runs as 
intended. 

Referring to F^ure 5, the script compiler 292 wifl now be descrgied. The DSQ lists that are in an electronic 
text format, such as ASCII, are collected by use of the script data development tool and then processed by the scrqjt 
compiler 292. B^ininng at a start state 420. the script compiler processes the source script for completeness, 
consistency and uniformity. Syntex errors are identified at this state. After any problem areas are corrected, the 
compiler proceeds to state 424 and converts the script from the source format to the stored file format, which is a 
binary format. Cont'muing at state 426, the script compiler 292 augments the script for access to the various MDATA 
databases, shown in F^re 2, and the MDATA infrastructure or support system. The script compiler completes at a 
return state 428. 

V. Script Execution Detafls 

Ovorviow 
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When a patent accesses the MDATA system 100 lor a diagnosis, the system manages the tnitiat contact with 
the patient, identifies the patient, decides which service the patient needs, selects the correct ms fib, and starts up 
the script engine. Tlie script engine loads the MDS file and bagins to obey its coded directions, one by one. The effect 
of obeying the coded directions is an interview with the patient. At the end of the interview, the script directs the 
engine to perform appropriate terminal actions (updating databases, ctesing fdes, logging the session) and ultimately 
returns computer control to the MDATA system 100. 

Using an MOS file to drive a script engine to conduct an on line interview is descnlied hereinbalow. The 
supporting operations required to access database files, output information to the patient, mput the patient's responses, 
and print reports, is performed by the underiymg operating system on which the script engine is runnEng. 

The run time mode of the List Based Processing method generates a IWDS file that is list-oriented. That means 
that, at each step, the disease, symptom, and question fists must be searched to determine the next question or action 
of the script. The script engine has to do more work using the fist-based method than a branch based methol 

The twos fife is, in essence, a medical encyclopedia of human diseases, stored in top-down order from a high- 
level list of diseases down to a single question that elicits one aspect of a symptom of one disease. To run such a data 
structure as a script requires that the structure be "inverted,'' Le., presented as a sequential question stream to the 
patient. To do this in the run time mode, the script engine first searches the master disease list of the MDS file to 
select the next disease to be considered. Then the engine searches the list of symptoms of the selected disease to select 
the next symptom to astt about Then the engine searches the question set for the selected symptom to select the next 
question to be asked. The engine poses the question to the patient obtabis the answer, updates the various weighted 
fists, and repeats the process until it reaches a diagnosis or runs out of diseases. The overaQ effect is to generate a 
diagnostic conversation between the script and the patient that concludes with a diagnosis. 

As the script runs, the script maintains the patient's symptom set as a temporary dynamic Rst called a "temp* 
list. Every new symptom is recorded in this set, and is used to update the Ibt of diseases being considered. The 
patient's responses thus build a health profOe that is used to select the next disease and symptom and question. The 
profile serves a number of uses: 

o it is used to update all diseases being considered, to aid m selecting the next drsease; 

^ it can be used to make statbtical con^arisons of cases; 

o it allows the MO ATA system to dynamically alter the question stream based on a specific patient's 
heahh state; 

o it allows the MDATA system to interrupt a script and to continue it later, fay storing the profile and 

retoading it at a later tene to continue the script 
When the script engine begins, it is gh/en an on line patient and a script O-e., a MDS ffle). The engine opens 
the twos file to establish access to the coded lists of diseases, symptoms, and questions, h also opens the patient 



wo 98/02836 IPCT/US97/1 2025 

•22- 

record to obtain the patient's medical history and the results of past sessfions, if any. wHh the pattern. From 
hereinf orward. the MDS fib drives the Intervbw by directing the engine to a next mterview step. At the end of the 
interview, the script dkects the engine to perform epproprate lerminal actions (updaiing databases, dosing files, logging 
the session) and uttonateiy returns computer control to the MDATA system. 
5 The aspect of interest for this explanation of list-Based Processmg is the algorithm used to question the patient 

and to budd up a set of symptoms toward a (fiagnosis. This algorithm consists of a main loop that analyzes and updates 
a set of patient sirmptoms until it reaches some conditbn that terminates the loop. The main loop includes the following 
general steps: 

o analyze the patient's set of symptoms, 
10 o select the disease to be conshfered next, 

9 select the symptom to be considered next, 

o select the question to be presented next, 

o present the question to the patient and process the response, 

o update the symptom set based on the response, 
15 ° perform post-response processing of the symptom set. 

o loop to analyze the patient's set of symptoms. 
This main loop continues until the script terminates with some exit action such as forming a diagnosis, giving Ueatment 
advice, or forwardmg the patient to enother script. 
Description o? the Seripft Eneeoiyon fiPreiRriBiQs 
20 Referrmg now to Figure Ba, a general configuration of the R/IDATA system for operating the diagnostic script 

engine 190 win now be described. The dtegnostic script engine ISO interfaces with a (WD ATA support system 440 so 
as to get access to a plurafrty of databases 442 of the MDATA system and to have input and output capabiBties with 
the various entities in the medical community. The MDATA support system 440 includes the processes shown in F^re 
2, including the login process 210, the registration process 212, and the diagnostic process 220. Abo inchjded in the 
25 MDATA support system 440 are processes for performing input and output to and from the physician 444, the patbat 
1 14, and health organizations 446, such as a health maintenance organization (HMOK The MDATA support system 440 
utilizes the communication network 102, previously shown in Figures la and lb. The databases 442 shown in Rgure 
6a bichide the databases pravbusly shown in Figure 2 and also mchide other databases such as for human diseases, 
drugs end drug interactions, human anatomy, a regubtory ratchet table, and a geographic distributbn of frequency of 
30 diseases. The regulatory retchat tabb is a tabb of regubtory and bgal "rubs" that tat the system bnow bow much 
information can be reveabd to a patient. 

Referring now to Rgure 6b, the structures and inputs and outputs utilized durmg the operation of the ifiagnostic 
script engine wiO now be described. Based on input from user 460, records from the patient medical history database 
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254 and other kifcrmation available from the central MDATA databases 442, a MDS 2SS is selected from the MDS 
database 30Q. Ahemativelv, if the diagnostic script engine 190 is run on a patient's personal computer, local user data 
storage 1B4 may be accessed in place of the MDATA databases stored at a central locatbn. Hocirever, it b more 
practical to tceep the patient medical history at a central database for several reasons: safety of the records, health care 
providers anywhere in the world have access as necessary for analysis, matching a diagnosis to any nevtf treatments so 
that a patient can be quicltty notified by the system, and so forth. 

The ms 296 is made available for the diagnostic script engine 190, which performs the pat'ent interview. 
The script engine 190 may write information received during the patient interview to either the central patient medical 
history database 254 or to the local user data storage 184. At the conclusion of the current scr^it, or if additranal 
scripts are run, medical diagnosis or advice 462 may be generated. This diagnosis or advice is preferably reported to 
the physician 464, output to the user 466 and stored in the central (WDATA databases or she local user data storage 
184. Other reports 468 may be generated as necessary. As wifl be described later, Xhme are situations where the 
diagnosis may not be reported directly to the user, but may be sent instead to the physician for further reporting to the 
user at a later time. 

Referring to Figure 7, a general top level process 480 for a user in a session with the ftfOATA system 100 wiD 
now be described. Process 4BD begins at a start state 481 and moves to state 482 to identify an emergency situation. 
A set of initial •'hard-coded" screening questions are utifoed to identify the emergency situation. If an emergency 
situation is identified, appropriate advice, such as calling 911, is provided to the user. State 482 and subsequent states 
484, 486 end 488 are substantially described in Applicant's copending application emitted "COfWPUTERIZED MEDICAL 
DIAGNOSTIC AMD TREATMENT ADVICE SYSTEM," U.S. Serial No. 08/176,041. If process 480 determines that there 
is no emergency situation, the process continues at state 484 and securely identifies the user. As described in 
AppDcanfs copendmg application, the user may be the patient or an assistant for the patient. Passwords, identification 
numbers, voice prints or other types of identification methods may be utilized. H the patient has logged in properly, 
process 480 continues at a state 486 to perform any necessary administrative taste. Proceeding to state 488, process 
480 access the MDATA medical databases (Figure 2) and the system fges and software. Proceeding to process 490, 
an on-line intervww with the user is conducted. The on-Dne interview preferably is performed by the diagnostic swipt 
engine process 490. However, other ways of performing the on-Fine interview may be utifized, such as running a program 
or esecuting a script. The user process 480 completes at an end state 49Z 

Referring now to Figure 8a, the diagnostic script enghe process 490 will be described. Beginning at a start 
state 492, the script engme process 490 proceeds to state 494 to perform a script router function. The script router 
selects an appropriate DSQ scrqjt based on input parameters such as: a patent's chief complaint symptoms, the time 
since the symptoms started, the patient's past medical history, results from any other scripts, or the results from the 
current script family from a prbr time. Identification of the patent's chief complaint is algorithmic. The chief complaints 



wo 98/02836 PCT/IUS97/1 2025 

-24- 

can be categortied into the foBowing classifications: an anatomic system involved, a causa of the patient's profatonv e.g^ 
trauma or infection, en alphabetic list of chief complaints, an tCD-9 number for their complaint, or a MDATA catalog 
number of their chief complaint. After the appropriate OSQ script has been selected, process 490 continues at state 
496 to retrieve the selected scr^t from the script database 300 (Figure 6b). At this tsne, the diegnostic script ragme 
5 process 490 invokes a DSQ fist script engine 500 to utibe the OSQ lists in performmg the intervtew with the patant. 
The DSQ list script engine 500 wiH be further descr&ed in conpinction with Figures 9 and 11. 

The diagnostic script engDie process 490 post-processes the results of the DSQ scr^t engine at state 50Z 
Various types of processing are performed at state 502, as eaempEf ed by states 506 through 526 described hereinbelow. 
One action that may be performed et state 502 mctudes determinmg a degree of certainty for diseases in the ruted-in 

10 disease list and in the ruied-oiit disease list. The degree of certainty for soma or afl the diagnoses tn the rutad-oi end 
ruled-out disease Ksts may be reported to the patient and/or physician. The diagnoses from the ruled-in and ruled-out 
disease lists and the associated degrees of certainty are compSed into a differential diagnosis list. Various ways of 
determining the degree of certainty for a diagnosis include, for example, a degree of certainty looE(Hip table or a 
sensitivity factor set Sensitivhy factors were previously described in Appficant's issued patent, U.S. Patent No. 

15 5,594,638, entitled "COA/lPUTERiZED MEDICAL DIAGNOSTIC SYSTEM INCLUDING RE ENTER FUNCTION AND 
SENSmvmr factors. ** The next action performed by process 490 is dependent on the result type as determined at 
a decbion state 504. Various exemplary result types will now be described. At state 506, the diagnostic script engkie 
process 490 refers the patient to another script, which is selected at state 494, as previously described. At state 508, 
process 490 generates appropriate medial diagnosb or advice. Moving to function 510, the advice b distributed to the 

20 appropriate party. Function 510 w31 be further described in conjunction with Figure 8b. After the advice b dbtr&uted, 
process 490 ends at an end state 512. 

At state 514, process 490 performs a special meta analysis. The diagnostic script engine studies how a 
specific symptom changes or grows over time in a given dbease. At state 516, process 490 stores the results 
accumulated during the scr^t mto the patient's records. At state 51 B, process 490 forwards the patient to access a 

25 medical information library that is part of the MDATA system 100. At state 520, process 490 schedules a later 
continuation of a script that was adjourned temporarily. TypicaOy, this occurs when a patient b not able to complete 
the entire script dunng a session, hi a situation where no dbease has reached a rule-in threshold, the diagnostic script 
engine has the capabiHty of providing a Bst of diseases that have the most weight in decreasing levels of probabity to 
the patient. In such a situation, at state 522, the process 490 could schedule a re-enter session to aBow a length of 

30 time to pass and sra if a diagnosb could be reached at a later time. The re-enter feature b described in Appicant's 
copending application entctted 'COMPUTERIZED MEDICAL DIAGNOSTIC AND TREATMENT ADVICE SYSTEM.* At state 
524, process 490 requests the patbnt to have tests performed and to consult the system again. These tests may 
include self-esam maneuvers, imaging modafity tests (258, Figure 2| or laboratory tests (260, Figure 2). At state 526, 
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process 490 forwards any urgent resufts to a health care provider for immediate action. Process 490 ends at the end 
state 512. 

Referring to Figure 8b, the distribute diagnosrs or advice function 510 win now be descried. Beginning at a 
start state 511, function 510 proceeds to state 512 wherein the results of the various lists are coUated due to one or 
more diseases or diagnoses reaching threshold. Proceeding to state 515. function 510 checks the treatment table for 
the appropriate and current treatment for the diagnoses made by the system. Proceeding to state 517, function 510 
determines who shouM be the rec^ieot of the diagnosis or advice. This is partially accomplished by consulting a 
regulatory ratchet table 519. The regulatory ratchet table determines the type of mformation that can be toU to the 
patient depending on various factors, such as what country the patient fives In. As a result of consulting the regulatory 
ratchet table 519, advice or a diagnosis is conununicated to the patient 114, a physician 444. a managed care 
organization 446 or other entity 521 that legally may have access or has a need to know the medical mformation. There 
is much information that could be shared with the patient and should be shared with the patient's physician. For 
example, what is ruled in and what is ruled out, and what is the patient's specific differential diagnosis? That is, after 
the patient answers aU of the questions, the scores for al of the different diseases can be ranked. This is very helpful 
to the physician. The r^ulatory ratchet table 519 utibes informatbn available in the patient's record, such as the 
patient's zip code or telephone area code to identify their location. 

Referring to F^ure 9, the DSQ script engine process 500 wiD now be described. Beginning at a start state 
530, the process 500 proceeds to state 532 to access the selected DSQ list file passed to it by the diagnostic script 
engine. Proceeding to state 534. process 500 initiattzes the temp Osts utifized by the script engine. Referring temporarily 
to Figure 10, process 500 inrttaEzes the symptom temp list 552 to be cleared and tnitiaOzes the disease temp Kst 550 
to have all of the diseases of the master disease list 324. At this point, process 500 selects one of the diseases to 
be processed and then selects a symptom to be asserted m the disease. To determine the presence or absence of the 
symptom in the patient, process 500 continues at state 536 to select the first question of the symptom to be asked 
of the patient. Al state 538, process 500 asks the question of the patient. Moving to state 540, process 500 receives 
the patient's response and checks for correctness of their response eccordmg to the asked question. The patient's 
response is used then to update the DSQ temp Ksts at state 542, 

Proceeding to a decision state 544, process 500 determines if a diagnosis or a terminus of the script has been 
reached, if it has not, process 500 proceeds to state 546 to select either the next question in the current syn^ptom, 
or, if all the questions for the current symptom have been asked, to proceed to the neat symptom for the current disease. 
If aU the questions in the current disease have been asked, process 500 moves to the next disease end asks the 
questions necessary for that disease. Process 500 loops at states 538 through 546 untB the end of the scr^it is 
reached, a diagnosis is achieved, the user requests the script to be adjourned, or the script engine determines that the 
script should be terminated. When the diagnosis or terminus has been reached, process 500 either returns the diagnosis 
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at state 541, refers the patient to a (Afferent script at state 543, adjourns the current script at state 545, or terniinatBS 
the current script at state 547. Process 500 comptetes at a return state 548. 

Referring now to Hgure 10, a portion of tha fists utilized durmg run tsne operstron of the DSQ Rst script engine 
500 win be described. Based on user input 460 and tfie time since the symptoms have begun, the script router 494 
5 {Figure 8a) of the diagnostic script engme 490 identifies a script to be passed to the DSQ list script engine 500. The 
records of the current patient from the pattern medical history 254 are also used by the script router 494. Using the 
medical diagnostic script recehfed from the script router, the DSQ Ibt script engine 500 accesses the master disease fist 
324. The diseases in the master disease list are copied to a disease temp Est 550. At the appropriate time during 
operation of the DSQ list script engine 500, symptoms from the master symptom fist 326 of the current disease are 

10 selecthrely copied to the symptom temp list 552, as will be described in conjunction with Figure 12. As symptoms are 
asserted during the patient interview, symptom weights and/or question weights for the symptoms w9 be added to the 
score for the current disease in the disease temp list 550. When a score for a particular disease reaches a rolad-in 
threshold, the disease is moved to the ruled-in disease list 554. Alternatively, if the score for the current disease reaches 
the ruled out disease threshold, the disease is moved to the ruled out disease list 556. Asserted symptoms, ruted in 

15 diseases, ruted out diseases, and diseases neither ruted in nor ruled-out may all be stored in the patient medical history 
254. At the completion of a script or at a terminus or checkpoint during the script, diseases left in the dbease temp 
list 550 may also be written to the patient medical history 254. Alternathrely, the patient syn^tom and disease 
information may be written to the local user data storage 184 (Figure 6b) instead of the central patient medial history 
254. 

20 Referring now to Figure 11, the operation of the DSQ fist script engine 500 wiR be described. This description 

win provide more detail than the overview of the script engine process provided in conjunction with Figure 9. Beginning 
at a start state 580, the script engine process 500 proceeds to state 582, wherein the disease ten^ list 550 is initialized 
from the scr^t master disease fist 324 (Figure 10). Moving to state 584, the script engine process accesses patient 
data from current and/or previous patient sessions. The script engine process 500 utizes the MDATA support system 

25 440 (Figure 6a) and the databases 442 to get the patient data and any other data necessary. Alternatively, the patnnt 
data may be retrieved from the tocel user data storage 184 (Figure 6b). 

Advancing to state 586, the script engine process 500 selects the disease to be considered. Various methods 
may be utized in selecting the order of the diseases to be considered. For enampla, the most urgent diseases may be 
considered first, followed by the serious diseases and then the common diseases. Ahernathrdy, or in conjunction with 

30 the urgent/serious model, the first diseases to be considered may be the most prevatent in the population that the patient 
is in. The script engine process may utilize the telephone number, postal z^ code, or other sources of location 
information from the patient's history to idemify the population group or location that the patient is in. An attemathre 
for selecting the disease order once the process has started is to use the disease with the highest total of symptom 
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weights, Le., the disease which is nearest to bmq diagnosed. Preferab^, the script coordinator arranges the diseases 
for the current script in the order the/ are to be considerel After the current disease to be considered is determined, 
the script engine process 500 proceeds to the **select srmptom to be considered" process 588. Process 588 determinBs 
the symptoms to be consMered tor the current disease and will be further descriied in conjunction with Figure 11 

Script engine process 500 checks to see If a selected symptom null flag, which may be set during process 58B, 
is asserted at decision state 590. If the selected symptom flag is null for the current disease, process 500 advances 
to a decision state 618 to determine tf there are more diseases to consider. However, if the selected symptom flag is 
not nult scrqit engine process 500 proceeds to state 592 to select the question flow to be presented to the patient. 
Associated with each symptom is a question logic flow that can elictt the symptom. A Cogic flow can be thought of as 
a 'complex question," i.e., a question that consists of several questions and can produce one of several answers. 
Preferably, the questbn flow which contains, i.e., can generate as a response, the symptom which currently has the 
highest chance of ruling in the disease under consideration should be selected. Advancing to state 594, script engine 
process 500 then executes the current flow node. Proceeding to state 596, script engine process 500 presents the 
question part of the flow node to the user. Every question preferably consists of a set of informatbn text, instruction 
text, and a question. To present the question, the script first outputs the information text to the patient, then the 
instruction text, and finally the question text. The question text mdicates to the patient that a response is expected at 
the present time. 

Continuing at a handle response process 598, the script engine processes the response from the user. Process 
598 will be further descr3)ed in conjunction with Figure 13. The flow node preferably b one of three types: symptom, 
question, or program. Script engine process 500 determines the flow node type at a decision state 600. If the node 
type is question or program, script engine process 500 moves to state 594 (question bop Q) to execute the next flow 
node. However, if the flow node type is of the symptom type, process 500 proceeds to state 802 to update the 
symptom temp list 552 (Figure 10), based on the received response from the patent. Based on the response, a weight 
is assigned for the current symptom. Alternatively, if the current symptom utilizes multiple questions, some of which 
have associated weights, the weight (if present) for the current question is accumulated for the current syn^ptom. 

When the DSQ script has obtained a symptom, it updates all diseases that have the symptom. That b, a smgfa 
answer from the patient can change the symptom weighing of aS diseases being considered. This "promotes" one or 
more diseases to being ctoser to the diagnostic thresholds. 

Proceeding to a function 604, the script engine process 500 performs post-response processing to further update 
the symptom temp fist 552. Examples of post-response processing inchide if-then relationships, simultaneous relatnmships, 
sequencing relatbnships and other similar types of relationships. For example, if a symptom severhy vahm is 9, then 
a weight of 75 might be added to the diagnosis of biiiary colic, and a weight of 50 might be subtracted from the 
diagnosis of appendicitis. Other post-response relationships were previously discussed tn conjunction with Figure 4b 
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(capture disease knowledge). After the post-response processing has been completedL the script engine process 500 
proceeds to the update disease lists process 606. At process 606. the script engine updates the scores in the disease 
temp fists based on the updated symptom temp list 552 and eliminates ruled-fli or ruled-out diseases. The update disease 
Hst process 606 w8l be further described m conjunction with Figure 14. 

At the completion off process 606, some diseases may be ruled in or ruled out, thereby reducing the length of 
the dbease temp list 550 (Figure 10). However, if either the ruled in threshold or the rubd-out threshoU has not bemi 
reached, the disease is not removed from the disease temp Kst. Thus, at state 608, an updated disease temp Bst and 
an updated symptom temp fist are teft for the next iteration of cheching synrtptoms for diseases. Moving to a decision 
state 610, the script engine process 500 determines if there are more symptoms in the symptom temp list 552 for the 
current disease. If so, the scrpt engine process 500 selects the symptom with the largest weight, based on absokite 
value, associated with it at state 612 and then proceeds to state 592 (symptom loop S) to select the question flow for 
that new symptom. However, if there are no aiblitional symptoms in the symptom tonp fist 552, as determined at 
decision state 610, the script engine process 500 proceeds to state 614 to delete the current disease from the disease 
temp list 550. 

Proceeding to the decbion state 816, the script engine process 500 determines If the disease temp list 550 
for the current script is empty. If it is not, the scrqit engme process 500 moves to state 586 (disease loop D) to 
consider the nest disease tn the script. If the dbease temp Ibt 550 for the current script b empty, the script engine 
process 500 proceeds to a decision state 618 to determine the type of result of the script. At state 820, one of the 
possible results b that one or nrare dbeases have been ruled in or have been ruled out. At state 622, another type of 
result b that the script engine has determined to reference another script or enother service. The script engine process 
500 completes at a return state 624 and returns to the diagnostic process 490 (Figure 8a}. 

Referring to Figure 12, the select symptom process 588, referenced in Figure 11, win now be descrSied. 
Beginning at a start state 640, the select symptom process 588 proceeds to state 642 to dear the symptom temp list 
552 (Figure 101 Proceeding to state 644, the select symptom process 588 accesses the current disease tn the script 
master dbease fist 324 (Figure 10). Advancing to state 646, process 588 identifies the nest symptom of the current 
dbease. Continuing at a decision state 848, process 568 determines if the symptom's question fbw has previously been 
executed for thb patient. For example, the symptom may have been determined in another disease or even in anothn 
script for thb patient. If the question flow has not been previously executed, process 588 proceeds to state 850 and 
adds the symptom to the symptom temp IbL After adding the symptom to the symptom temp Ibt, or if the symptom's 
question flow has beoi previously executed, process 588 moves to a decision state 652. At decbion state 652, process 
588 determines if there are more symptoms for the current dbease. If so, process 588 moves back to state 646 to 
identify the next symptom of the current dbease. 
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If there are no more symptoms for the current drsease, as determined at state 652, process 588 continues at 
a decision state 654 to determine if the symptom temp Ost 552 is empty. If it is, select symptom process 588 moves 
to state 656 to detete the current disease from the disease temp list 550. This would happen, for example, if all the 
symptoms for the disease had been previously considered at an earlier time in thb or another script. In tins situation, 
the select symptom process 588 returns at state 658 wiH a nut! symptom flag. Returning to decision state 654, if the 
select symptom process 588 determmes that the symptom t^ip Est is not empty, execution contmues at state 660 
wherein the symptom temp fist is sorted by the absolute vatua of the weight Proceeding to state 662, process 588 
selects the symptom with the largest absohite vahie of the weight. The select symptom process 588 returns at state 
664 to process 500 (Ftgure 11) with the selected symptom. 

Referring to Figure IX the handle response process 598. referenced in Figure 11, win nDw be described. 
Beginning at a start stale 690, process 598 proceeds to state 692 to check the vaBdity of a user response. Proceeifing 
to a decision state 694, process 598 determines H the response is valid. If the response is not vaBd, process 598 
proceeds to state 696 to repeat the output of the question text to the user and then moves back to state 692 to check 
the validity of the user response. A check for a time out situation occurs during the handle response process 598. The 
time-out is evahiated to see if it could mean a possible loss of consciousness or a change m mental status. If so, a 
mental status subroutine could be invoked or emergency medical personnel may be called, for example. 

If the response is determined to be vaM at the decision state 694, process 598 proceeds to a decision state 
698 to determine the type of node currenthr being processed by the DSQ script engine 500. If the node type is a 
symptom node, process 598 proceeds to state 700 to select the symptom value associated with the current flow node. 
A symptom node returns the symptom as the answer to the complex question. The symptom vahia is then returned at 
state 702 to the symptom script engine process 500 (Figure 111. If the node type is a question node, process 598 
proceeds to state 704 to convert the response to a path digit. Advancing to state 706, process 598 appends the path 
digit to the current flow node path name. State 704 and 706 are used to identify the next question node to be 
executed. Returning to decision state 698. rt the node type is determined to be a program node, process 598 proceeds 
to state 710. At state 710. process 598 executes the program indicated by the current node and gets a return digit. 
Contmumg at state 712, process 598 appends the return digit to the current flow node path name. State 710 and 712 
are used to identify the next question node to be executed. The program executed at state 710 may be a sub-script 
or other function or subroutine needed to elicit additionat medical information from the patient. At the completion of 
either state 706 or 712, process 598 returns at return state 708 to the OSQ script engine process 500 {Figure 11). 

Referring to Figure 14. the update disease lists process 606, referred to in Figure 1 1, win now be described. 
Beginning at a start state 730. process 606 proceeds to state 732 to access the disease temp fist 550 (Rgure 10). 
Continuing at a decision state 734, process 606 determines if there are more diseases in the disease temp list 550. 
If not process 606 returns at a return state 736 to the DSQ script engine process 500 (Figure 11). However, if there 



wo 98/02836 



30- 



PCT/US97/I2025 



10 



15 



20 



25 



30 



are more diseases in the temp Bst, process 606 proceeds to state 738 to access the next disease in the disease temp 
list 550. Proceeding to a decision state 740, process 608 determines if the current disease contains the symptom fust 
answered by the patiant or any of its post-response processed symptoms, such as determined at function 604 (Figure 
1 1K If so, process 606 moves to state 742 and adds the weight of the symptom just answered or the post-response 
process symptom to the score of the current disease* Proceeding to a decision state 744, process 606 determines if 
there are additional symptoms having weights that need to be added to the current disease score. This typically would 
happen if there are multiple post-response process symptoms. If so, process 606 moves bacEc to state 742 to add the 
weight of these additional symptoms to the disease score. If there are no more symptoms that need to be processed, 
as determined at state 744, process 606 proceeds to a decision state 746. 

At decision state 746, process 606 determines if the disease score has reached or pessed the ruted-in threshold. 
The ruled in threshold preferably has a value of 1,000, but other ruled in threshold scores could be utifized. If so, process 
606 proceeds to state 748 to add the current disease to the ruled in disease tet 554 (Figure 10). Movhg to state 750, 
process 606 deletes the current disease from the disease temp list 550 (Figure 10) and then moves back to decision 
state 734 to determine if there are more diseases in the temp list 550. 

Returning to decision state 746, if the score has been detennined to not reach or pass the ruled in threshold, 
process 606 proceeds to a decision state 752. At decision state 752, process 606 determines if the disease score has 
passed or has reached the ruled out threshold, (f so, process 606 moves to state 754 to add the current disease to the 
ruled-out disease list 556 (Figure 10). Advancing to state 750, process 606 deletes the disease from the disease temp 
list 550 and moves back to decision state 734 to check for additional diseases in the disease temp Sst 550. 

Returning to decision state 752, if the disease score is not tess than or equal to the ruled-out threshold, process 
606 moves back to decision state 734 to check for additional diseases in the temp list 550. Returning to decision state 
740, if the current disease does not contain the symptom just answered or any of its post-response processed symptoms, 
process 606 moves back to decision state 734 to check for additional diseases in the temp Est 550. 

The use of the ruled m threshoU and the ruled out threshold has c^tain implications as follows: 
the weight of a symptom can be given as a positive or negative number; 
two running scores are kept for each disease: one positive and one negathre; 
posithre weights are added to the positive score and negative weights to the negative score; 
weights are not subtracted; 

two threshold are used, a posithre one (e.g. 1000 or 10000) to rule diseases in and a negative one (e.g. -1000 
or 10000 to rule diseases out; 

when the posithfe score reaches or eaceeds the positive threshold, the disease is ruted-bi; 
when the negative score reaches or exceeds the negative threshoM, tim disease is ruled-out; 
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if a disease reaches neither threshold by the end of the script it is left in an "undectded" Est of diseases, 
which can be stored in the patient madicat history. 

Referring to Figure 15» an alternative embodiment for genn^ating medical advice or a diagnosis using branch- 
based scripts will now be descrBied. Beginning at a start state 782. the branch-basml script process 780 proceeds to 
state 784 to open a branch-based medical diagnostic script file. Proceeding to state 766, process 760 sets up the 
patient data from either current and/or previous sessmns with the patient. Script process 780 proceeds to state 788 
and starts at a first question m the script. Advancing to state 790. script process 780 presents the current question 
to the user. Continumg at state 792. script process 780 watts for a valid user response. Moving to state 794, script 
process 780 records the user response. At state 796. script process 780 goes to the node corresponding with the user 
response. Contkiuing at a decision state 798. script process 780 determines if the next node is an estt node. If not. 
process 780 continues at state 790 and presents the next question to the user. The script process 780 loops on states 
790 through 798 according to the sequence of the predetermined script nodes until an exit node is reached. When the 
exit node is reached, script process 780 moves to a decision state 800 to determine the type of result of the script. 
The branch-based script 780 may return a diagnosis at a return state 802. advice at a return state 804. or a reference 
to another script at a return state 806. 

VI. Advantages of Ltst Based Processing 
The List-Based Processing system provides advantages of speed, precision and completeness over other methods 
of medical diagnoses. Specifically, the list-Based Processing approach: 

_ organizes medical knowledge into fists that others can process; 

_ presents diagnosb in a way that can be checked for correctness and completeness; 

_ generates better scrqits than humans can write using branch-based scripts; 

_ simplifies updating scripts as medical knowledge changes; 

_ allows testing by automated means; 

can be used as a caDabte function from branch-based scripts; 
_ is computer pbtform-. medium-, and language-independent; 
_ albws scripts to be more easdy translated into other human languages; 
_ reftects the way doctors actually diagnose. 
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APPEWDIX 

EKEBAPLARY DSQ LBST-BASES) SmH 
This listing shows a more Bittensitfs sample of an ASCII fie that contains lists used as the startrng point for 
List-Based Processing. The list is intended only to show formats and relatbnships. It may not convey correct or 
complete medical information. The chief complaint for this esanptary script is 'malaise^ 



' MALARIA.TXT 



DEF H 

h_format 5 

h_comp 1 a in t s_ma 1 a i se 
END H 



DEF D 

d_falc "084.0" "Falciparum Malaria" 



s_tropics 200 

s_lethargic 100 

s_fever 200 

s_chills 200 

e_nochills -100 

s_sweats 200 

s_nosweats -lOO 

s_cfsinorder 200 

s_c f sno t inorder 100 

s_2 bou t s_o t he r 250 

s 3bouts other 250 
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sjpnotest 5 

s_jpnegative -700 
s_pfalcip 700 

sjpvivax -700 

s_povale -700 

s_pmalar -700 

s^jpmixed -700 



d vivax »084.l" "Vivax Malaria" 



s_tropics 200 

s_lethargic 100 

s_fever 200 

s_chills 200 

s_nochills -100 

B_sweats 200 

s_nosweats -100 

s_cfsinorder 200 
s_cf snotinorder 100 

s_2bouCs_4 8 350 

s_3bouts_4 8 450 

B_pnotest 5 

s_pnegative -700 

sjpfalcip -700 

s^pvivax 700 

s_povale -700 

s_pmalar -700 
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s^pmixed -700 



d__quartan "084.2" "Quartan Malaria" 

s_tropics 200 

5 s_lethargic 100 

s_fever 200 

s_chill6 200 

s_nochills -100 

s_sweats 200 

10 s_no8weats -100 

s_cfsinorder 200 

s_cf snotinorder 100 

s_2bouts_72 350 

s_3bouts_72 450 

15 s_pnotest 5 

s_pnegative -700 

s_pfalcip -700 

s_pvivax -700 

s_povale -700 

20 sjmalar 700 

8_pmixed -700 



d_ovale "084.3" "Ovale Malaria" 
s_tropics 200 
25 s_lethargic 100 
B fever 200 
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s_chills 200 

s_nochills -100 

s_sweats 200 

s_noBweats -100 

e_cfsinorder 200 
s_cf snot inorder 100 

s_2bouts_other 250 

s_3 bout smother 350 

s_pnoteet 5 

fi_pnegative -700 

s_pfalcip -700 

s_pvivax -700 

s_j)ovale 700 

sj)malar -700 

s_pmixed -700 



d mixed "084.5" "Mixed Malaria" 



s_tropics 200 

s_lethargic 100 

s_fever 200 

s_chills 200 

s_nochills -100 

s_sweats 200 

s_no8weat8 -100 

s cfsinorder 200 



s cf snotinorder 100 
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200 



s 2bouts other 200 



s 3bouts other 300 



10 



s_pnotest 
s_pnegative 
sjpf alcip 
s_pvivax 
s_p ovale 
s jmalar 
s_pTnixed 



5 

-700 
-700 
-700 
-700 
-700 
700 



15 



d_unspec "084.6" "Malaria, xinspec 



s_tropics 
6_lethargic 



s fever 



200 



100 



200 



s chills 



200 



s nochills 



-100 



s sweats 



200 



20 



s noBweats 



-100 



s cfsinorder 



200 



G cf snotinorder 100 



s_pnote6t 



100 



25 d notmal "Not Malaria" 



s nofever 



100 
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s_nochillB 
s_nosweat6 
s_nocf B 

s_cf snotinorder 

s jpnegative 

s_pfalcip 

s_pvivax 

s_povale 

e_pmalar 

sjpmixed 

END D 
DEP S 

s_malaise 

s_ tropics 

s_nottropics 

s_lethargic 

s_not lethargic 

s_f ever 

s_no fever 

s_chills 

s_nochills 

s_sweat6 

s_noeweatB 

s_nocf s 

s cfsinorder 
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300 

300 

700 

300 
1000 
-600 
-600 
-600 
-600 
-600 



f_tropics 
f_tropics 



"general ill feeling" 
"recently in tropics" 
"not recently in tropics" 



f_lethargic "has been tired/lethargic" 
f_lethargic "not tired/ lethargic" 



f_fever 
f_f ever 

f_chills 
f_chills 
f_sweats 
f_sweats 
f_cfs 

f Cf 5 



"has fever" 



"has no fever" 



"has chills" 



"has no chills" 



"has sweating" 
"has no sweating" 



"did not have CPS" 



"had CPS" 



V 
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s cf snotinorder f cfs 



10 



15 



20 



s_j)notest 
s_pnegative 
s_pf alcip 
s_pvivax 

r 

s_povale 

s^pmalar 

sj>mixed 

s_lbout_lday 

s_lbout_2 3 days 

s_lbout_other 

s_2bouts_48 

6_2bouts_72 

6_2bout smother 

s_3bouts_48 

s_3bouts_72 

s 3 bouts other 



END S 



DEF I 



s nochills 



s nofever 



3 nosweats 



f j>test 
f j)test 
f_ptest 
f_ptest 
f j>test 
fjtest 
f j>test 
f_cf s 
f_cfs 
f_cf s 
f_cf s 
f_cf s 
f_cfs 
f_cf s 
f_cfs 
f cfs 



"had CFS, but not in order" 



"not tested for Plasmodia" 



"plasm test negative" 
"teBt+ for P. falciparum" 



tf 



te6t+ for P. vivax" 



"test+ for P. ovale 



"test+ for P. malariae" 



"test+ for mixed Plasmodia" 



"1 CFS bout lasting 1 day" 
"1 CFS bout lasting 2-3 days 



"1 cfs bout of unk duration" 



"2 CFS bouts, 48h apart" 
"2 CFS bouts, 72h apart" 



"2 CFS bouts; unknown interval" 



"3+ CFS bouts every 4 8 hours" 
"3+ CFS bouts every 72 hours" 



"3+ CFS bouts of unk interval" 



s_nocf s 
s_nocf s 
s nocfs 



s chills s fever s sweats s cfs 



25 END I 
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DBF F 

f_tropics 

"1" q_tropics 
"II" s_tropic6 
"12" s_not tropics 
f_lethargic 

"1" q_lethargic 
"11" s_lethargic 
"12" s^notlethargic 
f_f ever 

"1" q_fever 
"11" s_f ever 
"12" s_nofever 
f_chills 

"1" q_chills 
"11" s_chills 
"12" s_nochills 
f_sweats 

"1" q_sweate 
" 11 " s^sweatB 
"12" s_nosweat8 
f_cfs 

"1" q_cfs 
"12" s_nocf B 

"11" q_cf Border 

"112" 8 cfsnotinorder 
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"111" q^cfsbouts 

"1110" s_nocfs 

"1111" q^dlbout 

"11111" s_lbou t _lday 
5 "11112" s_lbout_23days 

"11113" s_lbout_other 

"1112" q_d2boutB 

"11121" s_2boutB_48 

"11122" 6_2 bout s_7 2 
10 "11123" s_2bouts_other 

"1113" q_d3bouts 

"11131" s_3 bou C s_4 B 

"11132" s_3 bou t s_7 2 

"11133 » s_3boucs_other 
15 f jptest 

"1" q^ptest 

"12" s_pnotest 

"11" q_p found 

"110" s_pnegative 
20 "111" s_pfalcip 

"112" s_pvivax 

"113" s_povale 

"114" s_j)Tnalar 

"115" s_pinixed 
25 END P 
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DEF Q 



q_Cropics 


0 


t_qtropics 


12 


t_kyes 


t_kno 


q_lethargic 


0 


t_qlethargic 


12 


t_kye6 


t_kno 


q_f ever 


0 


t_qf ever 


12 


t_kyes 


t_kno 


q_chills 


0 


t_qchills 


12 


t_kyes 


t_kno 


q_sweats 


0 


t_qsweat6 


12 


t_kyes 


t^kno 


q_cf s 


0 


t_qcf s 


12 


t_kyes 


t_kno 


q_cf sorder 


0 


t_qcf sorder 


12 


t_kyes 


t_kno 


q ptest 


0 


t_qptest 


12 


t_kyes 


t_kno 


q_p found 


0 


t_qpfound 012345 


_knone t_falc t_viv t_ov t_mal t mix 


q_cf sbouts 


0 


t_qcf sbouts 


0123 


t_knone 


t_kone t_ktwo t_k3plus 


q_dlbout 


0 


t_qdlbout 


123 


t_kupiday 


t_k2 3days t_ko the r 


q_d2bouts 


0 


t_qd2 bouts 


123 


t^k4 Shours 


t_k72hours t__kother 


q_d3bouts 


0 


t_qd3bouts 


123 


t_k48hours 


t_k72hours t_kother 



END Q 



DEF T 

t_falc 
t_mal 
t_mix 
t_ov 
t viv 



FALCI PARUM 

MAXiARIAE 

MIXED 

OVALE 

VIVAX 



t_k23days 2-3 DAYS 
t_k3plus THREE+ 
t k4 8hours 4B HOURS 
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10 



15 



20 



t_)c72hours 


72 HOURS 


t_kno 


NO 


t_knone 


NONE 


t_kone 


ONE 


t_kother 


OTHER 


t_)ctwo 


TWO 


t_kuplday 


UP TO ONE DAY 


t_kyes 


YES 


t_qcf B 


Did you have 



t_qcf5bout6 How many bouts of C-F-S did you have? 
t_qcfsorder Did you have C-F-S in that order? 

Do you have chills? 
How long did that 1 bout last? 
What was the time between those 2 bouts? 



t_qchills 
t_qdlbout 
t_qd2bouts 
t_qd3 bouts 
t_q fever 



How far apart were these bouts? 
Do you have fever? 
t_qlethargic Have you been tired or lethargic? 
t^qpfound What Plasmodia were found in blood? 
t_qptest Did you have a blood test for Plasmodia? 

t_qsweats Do you have sweating? 

t_qtropics Have you been in the tropics recently? 



END T 



25 
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WHAT IS CLAIMED IS : 

1. A computerized diagnostic method, compreing the steps of: 

providing to a computer a Gst of diseases, each disease associated with a list of symptoms, and each 
symptom associated with a list of questlons; 

5 repetitively ashing questions to elicit responses, the responses establishing symptoms, each established 

symptom contributing a weight to a disease; and 

determining whether the accumulated weights for a disease reach or pass a threshold so as to declare 
a diagnosis. 

2. The method defined in Claim 1, wherein the symptom is established based on the presence or absence 
10 of one or more other symptoms. 

3. The method defined in Claim 1, wherein the presence of a selected set of symptoms adds additional 
weight to 3 diagnosis. 

4. The method defined in Claim 1, wherein a symptom at a first selected time of the diagnostic process 
is weighted differently then the symptom at a second selected time of the process. 

15 5. The method defined in Claim 1, wherein the weight of a symptom reported at a first severity is 

different than the weight of the symptom reported at a second severity. 

6. The method defined in Claim 1, wherein a selected set of symptoms occurring in a specified sequence 
over time lends a different accumulated we'^ht to the diagnosis than the accumulation of the individual weights of the 
selected set of symptoms not occurring in the specified sequence. 

20 7. The method defined in Claim 1. wherein a sequence of an onset or ending of a selected set of 

symptoms lends a different weight to the d^nosts than the accumulated individual weights of the selected symptoms 
alone. 

6. The method defined in Cla'mn 1, wherein the disease is ruled-in for further diagnostic inquiry based on 
the accumulated we^ht. 

25 9. The method defined in Claim 1, wherein the disease is niled-out for further diagnostic inquiry based 

on the accumulated weight. 
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10. The mathod defmed in Claim 1, wherein questions for diseases deemed urgent are asked before 
questions for non urgent diseases. 

11. The method defined in Claim 1, addrtionaDy comprising the step of determining whether the 
accumulated weights for a disease are less than a rule-out threshold so as to enminate a possible diagnosis. 

5 12. The method defined in Ciaun 8, wherein a degree of certainty of ruling in the disease is provided. 

13. The method defined in Claim 9, wherein a degree of certainty of ruling -out the disease is provided. 

14. The method defined in Claim 1, wherein a phiraBty of diagnoses, each diagnosis having a degree of 
certainty, are accumulated into a differential diagnosis Bst. 



10 




suBSTrruirE sheet (ruiile 2$) 
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SUBSHTIUTE SHEET {JWLE 26) 
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2f0 

V ^ 

^ ASSISTED LOGIN 
I [ASSISTANT LOGII^~ 




2/2 



ASSISTED 
REGISTRATION 



ASSISTANT 
REGISTRATION 



PATIENT 
REGISTRATION 
PROCESS 



DIAGNOSTIC 
PROCESS 



SCRIPT 
ENGINE 



META 



n FUTURE n 

LI IJ 





MSE 








SDER 








PMH 








PSE 








PMC 








SSA 





220 
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SOFTWARE STRUCTURES 



Reod/ 
Write 




PATIENT AND 
ASSISTANT 
ENROLLMENT 
DATABASE 



240 




250 



TREATMENT TABLE 



Read/ 
Write 




PENDING RLE 



Write 



252 



Reod/ 
Write 



PATIENT MEDICAL 
HISTORY 



254 



Read 



MDS DATABASE 



256 



Read 



IMAGING MODALITY 
OF CHOICE 



258 



Reod 



LABORATORY TEST 
OF CHOICE 



260 




SUBSTITUTE SHEET (RULE 25) 
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SUBSTOnUTE SHEET (ffSULE 26) 
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-^^^^ TIME 

SCRIPT I - TIME: T^ 
DISEASE A 



DISEASE B 




DISEASE X 



5/20 

BASED DSQ LISTS 



SYMPTOM A1 




SYMPTOM A2 




SYMPTOM Ay 



SYMPTOM B1 



SYMPTOM By 



SYMPTOM x1 



SYMPTOM xy 



QUESTION Alo 
QUESTION Alb 

O 

o 
o 

QUESTION Alz 

QUESTION A2a 
QUESTION A2b 



O 
o 





QUESTION 
QUESTION 



QUESTION 
QUESTION 

O 

o 
o 

QUESTION 
QUESTION 



QUESTION 
QUESTION 



QUESTION 
QUESTION 



A2z 
Aya 



Ayz 
Bla 



Biz 
Byo 

Byz 
xta 

xlz 
xya 



QUESTION xyz 



J22 



SCRIPT I - TIME: Tj 



DISEASE A 



DISEASE B 



O 
O 

o 




DISEASE X 





SYMPTOM A1 




SYMPTOM A2' 



O 

o 
o 



SYMPTOM Ay 



SYMPTOM By 



SYMPTOM x1 



O 

o 
o 



SYMPTOM xy 



SlIBSTBTUTE SHEET (RULE 26) 



QUESTION Ala' 
QUESTION Alb 



Q 

O 
O 




QUESTION Alz' 

QUESTION A2a 
QUESTION A2b' 



O 

o 
o 




QUESTION A2z 
QUESTION Aya 



O 

o 
o 



QUESTION Ayz* 
QUESTION Bla 



e 
o 
o 




QUESTION Biz 
QUESTION Byo 



O 

o 
o 




QUESTION Byz 
QUESTION »1a' 



O 

e 



QUESTION xlz' 
QUESTION xyo 



0 

9 



QUESTION xyz 



PCT/US97/I202S 



6/20 



ASSIGN DISEASES 




START 
ASSIGNMENT OF 
DISEASES 



1 




J52 



J50 



J54 



DEFINE CHIEF COMPLAINT 
FOR THIS SCRIPT 




J56 



DETERMINE LIST OF 
DISEASES DIAGNOSED BY 
THIS SCRIPT 




-J56 



RANK DISEASES BY 
PROBABILITY 
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FOR FURTHER 
DEVELOPMENT 
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FOR CRIPT 
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FOR EACH DISEASE. IDENTIFY 
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THRESHOLD SCORES 
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RELEVANT SYMPTOMS 
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FOR EACH DISEASE. IDENTIFY 
POST- RESPONSE RELATIONSHIPS 
AND ASSOCIATED SYMPTOMS 
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FOR EACH DISEASE SYMPTOM, 
ASSIGN A WEIGHT 
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FOR EACH SYMPTOM, DEFINE A 
FLOW OF QUESTION NODES TO 
ELICIT THE SYMPTOM 



FOR EACH QUESTION NODE, 
ASSIGN A WEIGHT 
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TEXTS PROVIDING INTRODUCTIONS. 
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PROCESS SOURCE SCRIPT 
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CONVERT SCRIPT FROM 
SOURCE TO STORED FILE 
FORMAT 
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AUGMENT SCRIPT FOR 
ACCESS TO MDATA 
DATABASES AND 
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IDENTIFY EMERGENCY 1^' 
SITUATION AND PROVIDE 
APPROPRIATE ADVICE 
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SECURELY IDENTIFY THE 
USER/PATIENT 
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PERFORM 
ADMINISTRATIVE TASKS 
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ACCESS MDATA MEDICAL 
DATABASES AND SYSTEM 
FILES/SOFTWARE 
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DIAGNOSTIC SCRIPT ENGINE PROCESS 

START 
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SELECT APPROPRIATE DSO SCRIPT BASED ON 
INPUT PARAMETERS SUCH AS: 
PATIENT'S CHIEF COMPLAINT-SYMPTOMS. 
TIME SINCE SYMPTOMS STARTED. 
PATIENT'S PAST MEDICAL HISTORY. 
ANY PREVIOUS SCRIPT RESULTS. 
CURRENT SCRIPT FAMILY RESULTS FROM 

PRIOR TIME 
(SCRIPT ROUTER) 
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RETRIEVE SELECTED SCRIPT 
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PERFORM SPECIAL META ANALYSIS 
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STORE RESULTS IN PATIENT RECORDS 



FORWARD PATIENT TO THE MEDICAL 
INFORMATION LIBRARY 
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ADVICE 
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SCHEDULE A LATER CONTINUATION OF SCRIPT 
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SCHEDULE A RE-ENTER SESSION 
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REQUEST PATIENT TO HAVE TESTS 
PERFORMED AND CONSULT SYSTEM AGAIN 
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COLLATE RESULTS 
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CHECH TREATMENT 
TABLE 
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DETERMINE 
RECIPIENT 
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ACCESS THE SELECTED DSQ 
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INITIALIZE THE TEMP LISTS 
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SELECT THE FIRST QUESTION 
FOR THE PATIENT 
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ASK THE QUESTION 
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INPUT AND PROCESS THE 
PATIENT RESPONSE 
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UPDATE THE DSQ TEMP LISTS 
BASED ON THE RESPONSE 



544 
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YES. 



DIAGNOSIS 
OR TERMINUS 
REACHED 



SELECT NEXT QUESTION 
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RETURN DIAGNOSIS 



REFER TO DIFFERENT SCRIPT 



ADJOURN CURRENT SCRIPT 
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TERMINATE CURRENT SCRIPT 
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DIAGNOSTIC LOOP/DSQ LIST SCRIPT ENGINE 
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INITIALIZE DISEASE TEMP LIST 
FROM SCRIPT MASTER DISEASE 

LIST 
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POST RESPONSE 
PROCESSING TO UPDATE 
SYMPTOM TEMP LIST 



SET UP PATIENT DATA (FROM 
CURRENT AND PREVIOUS 
SESSIONS) 
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SELECT THE DISEASE TO BE 
CONSIDERED 
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SELECT SYMPTOM TO BE 
CONSIDERED (FIG. 12) 
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UPDATE SCORES IN 
DISEASE TEMP LIST 
BASED ON UPDATED 

SYMPTOM TEMP LIST AND 
ELIMINATE DISEASES 

RULED- IN OR RULED- OUT 
(FIG. 14) 



LEAVE UPDATED DISEASE AND SYPTOM 
TEMP LISTS FOR THE NEXT ITERATION 




SELECT THE QUESTION FLOW 
TO BE PRESENTED 
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DELETE CURRENT DISEASE FROM 
DISEASE TEMP LIST 



EXECUTE THE CURRENT 
FLOW NODE 
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PRESENT THE QUESTION 
TO THE USER 
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PROCESS RESPONSE 
FROM THE USER 
(FIG. 13) 
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QUESTION OR 
PROGRAM .^FLOW NODE 

TYPE 



CONOmON(S) 
RULED IN/OUT 
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SYMPTOM 



UPDATE SYMPTOM TEMP LIST 
BASED ON THE RESPONSE 
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REFERENCE TO 
OTHER SCRIPT(S)/ 
SERVICES(S) 



RETURN 
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START 
SELECT SYMPTOM 
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CLEAR SYMPTOM 
TEMP LIST 
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ACCESS CURRENT 
DISEASE IN SCRIPT 
MASTER DISEASE 
LIST 
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IDENTIFY NEXT 
SYMPTOM OF 
CURRENT DISEASE 




ADD SYMPTOM TO 
SYMPTOM TEMP 
LIST 



YES 



632 

MORE 
SYMPTOMS FOR 
CURRENT 
DISEASE 
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NO 



654 



YES 



IS SYMPTOM 
TEMP LIST 
EMPTY 



.NO 
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656 



SORT SYMPTOM 
TEMP LIST BY 
WEIGHT 



DELETE CURRENT 
DISEASE FROM 
DISEASE TEMP 
LIST 
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SELECT SYMPTOM 
WITH LARGEST 
WEIGHT 
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RETURN 
(NULL 
SYMPTOM) 




RETURN 
(SELECTED 
SYMPTOM) 
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CHECK VALIDITY OF 
USER RESPONSE 
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VALID -^No 
RESPONSE 



SYMPTOM 
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SELECT SYMPTOM 

VALUE 
ASSOCIATED WITH 
CURRENT FLOW 

NODE 
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REPEAT OUTPUT OF 
QUESTION TEXT TO 
USER 
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PROGRAM 



QUESTION 



CONVERT 
RESPONSE 
TO PATH 
DIGIT 
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EXECUTE 
PROGRAM 
INDICATED BY 
NODE AND GET 
RETURNED DIGIT 
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APPEND 
PATH DIGIT 
TO CURRENT 
FLOW NODE 
PATH NAME 
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APPEND RETURNED 
DIGIT TO 
CURRENT 
FLOW NODE 
PATH NAME 
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RETURN 
(UPDATE SYMPTOM 
TEMP LIST) 
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RETURN 
(EXECUTE CURRENT 
FLOW NODE) 
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UPDATE DISEASE LIST 
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ADD WEIGHT OF SYMPTOM OR 
POST- RESPONSE PROCESSES 
SYMPTOM TO DISEASE SCORE 




ADO DISEASE TO 
RULED- IN DISEASE LIST 




ADD DISEASE TO 
RULE- OUT DISEASE LIST 
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DELETE DISEASE 
FROM DISEASE 
TEMP UST 
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BRANCH- BASED SCRIPT 
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OPEN MDS FILE 
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SET UP PATIENT DATA 
(FROM CURRENT AND 
PREVIOUS SESSIONS) 



START AT A FIRST 
QUESTION 
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PRESENT THE CURRENT 
QUESTION TO THE 
USER 
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WAIT FOR VALID USER 
RESPONSE 
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RECORD THE USER 
RESPONSE 




GO TO THE NODE FOR 
THE USER RESPONSSE 
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